Date: Mon, 20 Nov 2023 09:14:27 -0700 From: Warner Losh <imp@bsdimp.com> To: Cy Schubert <Cy.Schubert@cschubert.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: <CANCZdfrxJ5UE0XpFgroZob_rCBVOiMzG0K808ubpZseVKnsdqw@mail.gmail.com> In-Reply-To: <20231120080109.34bb47d6@slippy> References: <CANCZdfpZNaC6vqaLkOk2hbtFpmi6oLEVWNQgK2RTVofsJr%2Be9A@mail.gmail.com> <20231120080109.34bb47d6@slippy>
next in thread | previous in thread | raw e-mail | index | archive | help
--0000000000006ffda9060a97c8be Content-Type: text/plain; charset="UTF-8" On Mon, Nov 20, 2023, 9:01 AM Cy Schubert <Cy.Schubert@cschubert.com> wrote: > 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? > Need? No. There's nothing that will break. Will I do it anyway? Yes. "Can't fail" changes to this file has burnt me in the past... Warner -- > 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 > --0000000000006ffda9060a97c8be 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 Mon, Nov 20, 2023, 9:01 AM Cy Schubert <<a href= =3D"mailto:Cy.Schubert@cschubert.com">Cy.Schubert@cschubert.com</a>> wro= te:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b= order-left:1px #ccc solid;padding-left:1ex">On Sun, 19 Nov 2023 20:44:49 -0= 700<br> Warner Losh <<a href=3D"mailto:imp@bsdimp.com" target=3D"_blank" rel=3D"= noreferrer">imp@bsdimp.com</a>> wrote:<br> <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> Would we need an exp-run to find ports that might need some attention?<br><= /blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">Need?= No. There's nothing that will break.</div><div dir=3D"auto"><br></div>= <div dir=3D"auto">Will I do it anyway? Yes. "Can't fail" chan= ges to this file has burnt me in the past...</div><div dir=3D"auto"><br></d= iv><div dir=3D"auto">Warner</div><div dir=3D"auto"><br></div><div dir=3D"au= to"><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote clas= s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad= ding-left:1ex"> -- <br> Cheers,<br> Cy Schubert <<a href=3D"mailto:Cy.Schubert@cschubert.com" target=3D"_bla= nk" rel=3D"noreferrer">Cy.Schubert@cschubert.com</a>><br> FreeBSD UNIX:=C2=A0 <cy@FreeBSD.org>=C2=A0 =C2=A0Web:=C2=A0 <a href= =3D"https://FreeBSD.org" rel=3D"noreferrer noreferrer" target=3D"_blank">ht= tps://FreeBSD.org</a><br> NTP:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<<a href=3D"mailto:cy@nwtim= e.org" target=3D"_blank" rel=3D"noreferrer">cy@nwtime.org</a>>=C2=A0 =C2= =A0 Web:=C2=A0 <a href=3D"https://nwtime.org" rel=3D"noreferrer noreferrer"= target=3D"_blank">https://nwtime.org</a><br>; <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 e^(i*pi)+1=3D0<br> </blockquote></div></div></div> --0000000000006ffda9060a97c8be--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrxJ5UE0XpFgroZob_rCBVOiMzG0K808ubpZseVKnsdqw>