Date: Mon, 20 Nov 2023 08:01:09 -0800 From: Cy Schubert <Cy.Schubert@cschubert.com> 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: <20231120080109.34bb47d6@slippy> 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 Sun, 19 Nov 2023 20:44:49 -0700 Warner Losh <imp@bsdimp.com> wrote: > Greetings, > > 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). > > 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. > > 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). > > 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. > > 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. > > 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'. > > Comments? Suggestions? > > Warner Would we need an exp-run to find ports that might need some attention? -- Cheers, Cy Schubert <Cy.Schubert@cschubert.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: https://FreeBSD.org NTP: <cy@nwtime.org> Web: https://nwtime.org e^(i*pi)+1=0
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20231120080109.34bb47d6>