Date: Mon, 20 Nov 2023 11:50:21 +0800 From: Zhenlei Huang <zlei@FreeBSD.org> To: Warner Losh <imp@bsdimp.com> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: Some K&R support to be removed from sys/cdefs.h Message-ID: <FD5AA95F-C285-40EF-979E-BDC3D9724805@FreeBSD.org> In-Reply-To: <CANCZdfpZNaC6vqaLkOk2hbtFpmi6oLEVWNQgK2RTVofsJr%2Be9A@mail.gmail.com> References: <CANCZdfpZNaC6vqaLkOk2hbtFpmi6oLEVWNQgK2RTVofsJr%2Be9A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Nov 20, 2023, at 11:44 AM, Warner Losh <imp@bsdimp.com> wrote: >=20 > 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 Yeh, cheers ! Let's move ahead. > Comments? Suggestions? >=20 > Warner Best regards, Zhenlei
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FD5AA95F-C285-40EF-979E-BDC3D9724805>