Date: Sun, 19 Nov 2023 21:25:05 -0700 From: Warner Losh <imp@bsdimp.com> To: Robert Clausecker <fuz@freebsd.org> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: Some K&R support to be removed from sys/cdefs.h Message-ID: <CANCZdfr%2BAczgcmPxcho0nuqK%2BmMNxTJt%2BynJSi5XhRv6NudYPQ@mail.gmail.com> 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
--0000000000008cb4a5060a8ddfb3 Content-Type: text/plain; charset="UTF-8" On Sun, Nov 19, 2023, 9:15 PM Robert Clausecker <fuz@freebsd.org> wrote: > Hi Warner, > > __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. > The only way to eliminate them is to rewrite them as same macros with different names. That's why I said they were fine and I'd not touch them except to remove the entire !__STDC__ clause with at this point should have no effect. Warner Yours, > Robert Clausecker > > Am Sun, Nov 19, 2023 at 08:44:49PM -0700 schrieb Warner Losh: > > 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 > > -- > () ascii ribbon campaign - for an 8-bit clean world > /\ - against html email - against proprietary attachments > --0000000000008cb4a5060a8ddfb3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" = class=3D"gmail_attr">On Sun, Nov 19, 2023, 9:15 PM Robert Clausecker <<a= href=3D"mailto:fuz@freebsd.org">fuz@freebsd.org</a>> wrote:<br></div><b= lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px = #ccc solid;padding-left:1ex">Hi Warner,<br> <br> __STRING and __CONCAT are still needed with ANSI C to change evaluation ord= er.<br> For example, I recently used __CONCAT in lib/libc/amd64/amd64_archlevel.h t= o<br> build function names from pieces.=C2=A0 ## cannot be used as that doesn'= ;t work if<br> the argument passed to the macro is in turn a macro.=C2=A0 Similar things a= pply to<br> __STRING.<br></blockquote></div></div><div dir=3D"auto"><br></div><div dir= =3D"auto">The only way to eliminate them is to rewrite them as same macros = with different names. That's why I said they were fine and I'd not = touch them except to remove the entire !__STDC__ clause with at this point = should have no effect.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"a= uto">Warner</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div class= =3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8= ex;border-left:1px #ccc solid;padding-left:1ex"> Yours,<br> Robert Clausecker<br> <br> Am Sun, Nov 19, 2023 at 08:44:49PM -0700 schrieb Warner Losh:<br> > Greetings,<br> > <br> > I've had a long-term background project of cleaning up cdefs.h. So= far it's<br> > all been things that are definitely unused. My next target are some<br= > > specialized macros used to share code between K&R and ANSI-C compi= lers. K&R<br> > support in general will remain unchanged by this (any code using these= <br> > macros that wants to continue will need to arrange for that in their b= uild<br> > system). It may surprise many to learn with about 30 flags on the comm= and<br> > line, one can compile unmodified code from the 80s that conforms to th= e V7<br> > K&R language spec (for some not terrible definition of conforms to= a<br> > squishy spec).<br> > <br> > The support I'm talking about is __P, __CONCAT, __STRING, defining= __const,<br> > __inline, __signed and __volatile to nothing (only on some compilers) = and<br> > sometimes defining const, inlined, signed and volatile to nothing when= <br> > building when __STDC__ is not defined. This support was a transition f= rom a<br> > time, predating the FreeBSD project for the most part, when numerous<b= r> > programs were specially curated so they could build on K&R compile= rs as<br> > well as the then newly emergent ANSI-C compilers that were appearing. = The<br> > need to do this has long since past, so I'll be removing the pre-a= nsi-c<br> > build environment support for doing this specific thing.<br> > <br> > I'll retain __P, __const, __signed and __volatile in __STDC__ envi= ronments,<br> > but have firm plans to remove them completely in a future round. I'= ;ve<br> > already removed all __P usage from the tree (except sendmail). The oth= ers<br> > have a smattering of long-dead-hand-of-the-past usage in the tree (in = libm,<br> > for example). I plan on leaving __inline unchanged because it has a<br= > > secondary meaning. I suspect the only wide-spread one that will cause = me<br> > grief is __P. All the others I see occasionally, but it's not perv= asive<br> > like __P once was (and still is in older projects, shocking at that ma= y be).<br> > <br> > I have no plans on eliminating __CONCAT or __STRING. Their use is<br> > widespread in the tree is extensive, and where they are used, it's= fine.<br> > There's no need to gratuitously churn things here. To the extent t= hat pure<br> > K&R compilers are including our system headers, this will represen= t one<br> > more tiny step away from supporting that (as they are used in our head= ers).<br> > But such environments need their own headers anyway: all our headers u= se<br> > ANSI-C prototypes w/o __P protection.<br> > <br> > As with all my cdefs cleanups, I'll do exp runs before I commit. F= or the<br> > more consequential ones, I plan on posting reviews. For the other myri= ad of<br> > completely unused and designed to tell gcc3 from gcc4 or gcc2 from gcc= 3,<br> > I'm just going to eliminate those.There's no point in keeping = them once I<br> > make sure nothing in ports uses them.<br> > <br> > I suspect nobody will care, except to cheer on the removal of<br> > no-longer-needed junk that makes cdefs.h hard to read. My timeline for= this<br> > and other cleanup of cdefs.h is 'before 15 branches'.<br> > <br> > Comments? Suggestions?<br> > <br> > Warner<br> <br> -- <br> ()=C2=A0 ascii ribbon campaign - for an 8-bit clean world <br> /\=C2=A0 - against html email=C2=A0 - against proprietary attachments<br> </blockquote></div></div></div> --0000000000008cb4a5060a8ddfb3--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfr%2BAczgcmPxcho0nuqK%2BmMNxTJt%2BynJSi5XhRv6NudYPQ>