Date: Mon, 20 Nov 2023 04:19:11 +0000 From: Jessica Clarke <jrtc27@freebsd.org> To: Robert Clausecker <fuz@freebsd.org> Cc: Warner Losh <imp@bsdimp.com>, freebsd-arch@freebsd.org Subject: Re: Some K&R support to be removed from sys/cdefs.h Message-ID: <50B3506F-B0BF-4695-A0B5-CFDB918D6DAB@freebsd.org> In-Reply-To: <ZVrdSxgDZdepRZeL@fuz.su> References: <CANCZdfpZNaC6vqaLkOk2hbtFpmi6oLEVWNQgK2RTVofsJr%2Be9A@mail.gmail.com> <ZVrdSxgDZdepRZeL@fuz.su>
next in thread | previous in thread | raw e-mail | index | archive | help
On 20 Nov 2023, at 04:15, Robert Clausecker <fuz@freebsd.org> wrote: >=20 > Hi Warner, >=20 > __STRING and __CONCAT are still needed with ANSI C to change = evaluation order. > For example, I recently used __CONCAT in = lib/libc/amd64/amd64_archlevel.h to > build function names from pieces. ## cannot be used as that doesn't = work if > the argument passed to the macro is in turn a macro. Similar things = apply to > __STRING. You mean __XSTRING; __CONCAT is to __XSTRING what __CONCAT1 is to = __STRING, confusingly (though __CONCAT1 is unused except for implementing = __CONCAT). Jess > Yours, > Robert Clausecker >=20 > Am Sun, Nov 19, 2023 at 08:44:49PM -0700 schrieb Warner Losh: >> Greetings, >>=20 >> I've had a long-term background project of cleaning up cdefs.h. So = far it's >> all been things that are definitely unused. My next target are some >> specialized macros used to share code between K&R and ANSI-C = compilers. K&R >> support in general will remain unchanged by this (any code using = these >> macros that wants to continue will need to arrange for that in their = build >> system). It may surprise many to learn with about 30 flags on the = command >> line, one can compile unmodified code from the 80s that conforms to = the V7 >> K&R language spec (for some not terrible definition of conforms to a >> squishy spec). >>=20 >> The support I'm talking about is __P, __CONCAT, __STRING, defining = __const, >> __inline, __signed and __volatile to nothing (only on some compilers) = and >> sometimes defining const, inlined, signed and volatile to nothing = when >> building when __STDC__ is not defined. This support was a transition = from a >> time, predating the FreeBSD project for the most part, when numerous >> programs were specially curated so they could build on K&R compilers = as >> well as the then newly emergent ANSI-C compilers that were appearing. = The >> need to do this has long since past, so I'll be removing the = pre-ansi-c >> build environment support for doing this specific thing. >>=20 >> I'll retain __P, __const, __signed and __volatile in __STDC__ = environments, >> but have firm plans to remove them completely in a future round. I've >> already removed all __P usage from the tree (except sendmail). The = others >> have a smattering of long-dead-hand-of-the-past usage in the tree (in = libm, >> for example). I plan on leaving __inline unchanged because it has a >> secondary meaning. I suspect the only wide-spread one that will cause = me >> grief is __P. All the others I see occasionally, but it's not = pervasive >> like __P once was (and still is in older projects, shocking at that = may be). >>=20 >> I have no plans on eliminating __CONCAT or __STRING. Their use is >> widespread in the tree is extensive, and where they are used, it's = fine. >> There's no need to gratuitously churn things here. To the extent that = pure >> K&R compilers are including our system headers, this will represent = one >> more tiny step away from supporting that (as they are used in our = headers). >> But such environments need their own headers anyway: all our headers = use >> ANSI-C prototypes w/o __P protection. >>=20 >> As with all my cdefs cleanups, I'll do exp runs before I commit. For = the >> more consequential ones, I plan on posting reviews. For the other = myriad of >> completely unused and designed to tell gcc3 from gcc4 or gcc2 from = gcc3, >> I'm just going to eliminate those.There's no point in keeping them = once I >> make sure nothing in ports uses them. >>=20 >> I suspect nobody will care, except to cheer on the removal of >> no-longer-needed junk that makes cdefs.h hard to read. My timeline = for this >> and other cleanup of cdefs.h is 'before 15 branches'. >>=20 >> Comments? Suggestions? >>=20 >> Warner >=20 > --=20 > () ascii ribbon campaign - for an 8-bit clean world=20 > /\ - against html email - against proprietary attachments >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50B3506F-B0BF-4695-A0B5-CFDB918D6DAB>