Re: git: 17a238a15fbe - main - cdefs: Remove __func__ define
- In reply to: John Baldwin : "Re: git: 17a238a15fbe - main - cdefs: Remove __func__ define"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 27 Nov 2023 18:13:27 UTC
On Mon, Nov 27, 2023 at 10:50 AM John Baldwin <jhb@freebsd.org> wrote: > On 11/26/23 9:25 PM, Warner Losh wrote: > > The branch main has been updated by imp: > > > > URL: > https://cgit.FreeBSD.org/src/commit/?id=17a238a15fbed01477fbc54744d35cbccdb65871 > > > > commit 17a238a15fbed01477fbc54744d35cbccdb65871 > > Author: Warner Losh <imp@FreeBSD.org> > > AuthorDate: 2023-11-20 23:34:22 +0000 > > Commit: Warner Losh <imp@FreeBSD.org> > > CommitDate: 2023-11-27 05:24:02 +0000 > > > > cdefs: Remove __func__ define > > > > We require an ANSI-C compiler to build the base system. It's > required > > that __func__ work. Remove this define since the only known problem > > compilers are ancient history (gcc 2.6 from 1994, almost pre-dating > the > > project). 3rd party code that used this define will now need to > provide > > it via some other means when using non-ansi-c compilers. > > > > PR: 275221 (exp-run) > > Sponsored by: Netflix > > --- > > sys/sys/cdefs.h | 40 > ++------------------------------------ > > tests/sys/opencrypto/cryptodevh.py | 4 ---- > > 2 files changed, 2 insertions(+), 42 deletions(-) > > > > diff --git a/sys/sys/cdefs.h b/sys/sys/cdefs.h > > index c5b6190077b3..bcbf418f9323 100644 > > --- a/sys/sys/cdefs.h > > +++ b/sys/sys/cdefs.h > > @@ -96,14 +96,9 @@ > > /* > > * The __CONCAT macro is used to concatenate parts of symbol names, > e.g. > > * with "#define OLD(foo) __CONCAT(old,foo)", OLD(foo) produces oldfoo. > > - * The __CONCAT macro is a bit tricky to use if it must work in non-ANSI > > - * mode -- there must be no spaces between its arguments, and for nested > > - * __CONCAT's, all the __CONCAT's must be at the left. __CONCAT can > also > > - * concatenate double-quoted strings produced by the __STRING macro, but > > - * this only works with ANSI C. > > * > > * __XSTRING is like __STRING, but it expands any macros in its > argument > > - * first. It is only available with ANSI C. > > + * first. > > */ > > #if defined(__STDC__) || defined(__cplusplus) > > #define __P(protos) protos /* full-blown ANSI C */ > > @@ -122,33 +117,7 @@ > > #define __inline /* delete GCC keyword */ > > #endif /* ! __CC_SUPPORTS___INLINE */ > > #endif /* !__cplusplus */ > > - > > -#else /* !(__STDC__ || __cplusplus) */ > > -#define __P(protos) () /* traditional C > preprocessor */ > > -#define __CONCAT(x,y) x/**/y > > -#define __STRING(x) "x" > > - > > -#if !defined(__CC_SUPPORTS___INLINE) > > -#define __const /* delete pseudo-ANSI C > keywords */ > > -#define __inline > > -#define __signed > > -#define __volatile > > -/* > > - * In non-ANSI C environments, new programs will want ANSI-only C > keywords > > - * deleted from the program and old programs will want them left alone. > > - * When using a compiler other than gcc, programs using the ANSI C > keywords > > - * const, inline etc. as normal identifiers should define > -DNO_ANSI_KEYWORDS. > > - * When using "gcc -traditional", we assume that this is the intent; if > > - * __GNUC__ is defined but __STDC__ is not, we leave the new keywords > alone. > > - */ > > -#ifndef NO_ANSI_KEYWORDS > > -#define const /* delete ANSI C keywords > */ > > -#define inline > > -#define signed > > -#define volatile > > -#endif /* !NO_ANSI_KEYWORDS */ > > -#endif /* !__CC_SUPPORTS___INLINE */ > > -#endif /* !(__STDC__ || __cplusplus) */ > > +#endif /* __STDC__ || __cplusplus */ > > > > /* > > * Compiler-dependent macros to help declare dead (non-returning) and > > @@ -343,11 +312,6 @@ > > #define __unreachable() ((void)0) > > #endif > > > > -/* XXX: should use `#if __STDC_VERSION__ < 199901'. */ > > -#if !__GNUC_PREREQ__(2, 7) > > -#define __func__ NULL > > -#endif > > - > > #if (defined(__GNUC__) && __GNUC__ >= 2) && !defined(__STRICT_ANSI__) > || __STDC_VERSION__ >= 199901 > > #define __LONG_LONG_SUPPORTED > > #endif > > This removed a lot more than just __func__? > Damn. It looks like future work got folded in here by accident... This is the 'remove support for pure K&R compilers' stuff I've talked about elsewhere. I'll revert and fix. Warner