Date: Sun, 19 Nov 2023 20:44:49 -0700 From: Warner Losh <imp@bsdimp.com> To: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Some K&R support to be removed from sys/cdefs.h Message-ID: <CANCZdfpZNaC6vqaLkOk2hbtFpmi6oLEVWNQgK2RTVofsJr%2Be9A@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
--000000000000b44562060a8d4e72 Content-Type: text/plain; charset="UTF-8" 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 --000000000000b44562060a8d4e72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Greetings,</div><div><br></div><div>I've had a lo= ng-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 mac= ros used to share code between K&R and ANSI-C compilers. K&R suppor= t in general will remain unchanged by this (any code using these macros tha= t wants to continue will need to arrange for that in their build system). I= t may surprise many to learn with about 30 flags on the command line, one c= an compile unmodified code from the 80s that conforms to the V7 K&R lan= guage spec (for some not terrible definition of conforms to a squishy spec)= .<br></div><div><br></div><div>The support I'm talking about is __P, __= CONCAT, __STRING, defining __const, __inline, __signed and __volatile to no= thing (only on some compilers) and sometimes defining const, inlined, signe= d 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 bui= ld 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 specifi= c thing.</div><div><br></div><div>I'll retain __P, __const, __signed an= d __volatile in __STDC__ environments, but have firm plans to remove them c= ompletely in a future round. I've already removed all __P usage from th= e 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 __inl= ine unchanged because it has a secondary meaning. I suspect the only wide-s= pread one that will cause me grief is __P. All the others I see occasionall= y, but it's not pervasive like __P once was (and still is in older proj= ects, shocking at that may be).<br></div><div><br></div><div>I have no plan= s 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 t= o gratuitously churn things here. To the extent that pure K&R compilers= are including our system headers, this will represent one more tiny step a= way from supporting that (as they are used in our headers). But such enviro= nments need their own headers anyway: all our headers use ANSI-C prototypes= w/o __P protection.<br></div><div><br></div><div>As with all my cdefs clea= nups, 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 el= iminate those.There's no point in keeping them once I make sure nothing= in ports uses them.</div><div><br></div><div>I suspect nobody will care, e= xcept to cheer on the removal of no-longer-needed junk that makes cdefs.h h= ard to read. My timeline for this and other cleanup of cdefs.h is 'befo= re 15 branches'.<br></div><div><br></div><div>Comments? Suggestions?</d= iv><div><br></div><div>Warner<br></div></div> --000000000000b44562060a8d4e72--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpZNaC6vqaLkOk2hbtFpmi6oLEVWNQgK2RTVofsJr%2Be9A>