Date: Mon, 20 Nov 2023 17:44:56 -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: <CANCZdfrHMT88s1Zem-_N7Jkd-M2DgG_akwQqCQdvmggC70kkog@mail.gmail.com> In-Reply-To: <CANCZdfrxJ5UE0XpFgroZob_rCBVOiMzG0K808ubpZseVKnsdqw@mail.gmail.com> References: <CANCZdfpZNaC6vqaLkOk2hbtFpmi6oLEVWNQgK2RTVofsJr%2Be9A@mail.gmail.com> <20231120080109.34bb47d6@slippy> <CANCZdfrxJ5UE0XpFgroZob_rCBVOiMzG0K808ubpZseVKnsdqw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--00000000000007e54f060a9eeacb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 20, 2023 at 9:14=E2=80=AFAM Warner Losh <imp@bsdimp.com> wrote: > > > 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 th= e >> 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 a= s >> > 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 pervasiv= e >> > like __P once was (and still is in older projects, shocking at that ma= y >> 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 fin= e. >> > 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 on= e >> > 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 u= se >> > ANSI-C prototypes w/o __P protection. >> > >> > As with all my cdefs cleanups, I'll do exp runs before I commit. For t= he >> > 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 gcc= 3, >> > I'm just going to eliminate those.There's no point in keeping them onc= e >> 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... > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D275221 has the exp run queued up. And the changes if people want to look. Warner > 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=3D0 >> > --00000000000007e54f060a9eeacb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Mon, Nov 20, 2023 at 9:14=E2=80=AF= AM Warner Losh <<a href=3D"mailto:imp@bsdimp.com">imp@bsdimp.com</a>>= wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px = 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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"mailt= o:Cy.Schubert@cschubert.com" target=3D"_blank">Cy.Schubert@cschubert.com</a= >> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px= 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On = Sun, 19 Nov 2023 20:44:49 -0700<br> Warner Losh <<a href=3D"mailto:imp@bsdimp.com" rel=3D"noreferrer" target= =3D"_blank">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></blockquote><div><= br></div><div><a href=3D"https://bugs.freebsd.org/bugzilla/show_bug.cgi?id= =3D275221">https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D275221</a>; h= as the exp run queued up.<br></div><div><br></div><div>And the changes if p= eople want to look.</div><div><br></div><div>Warner</div><div>=C2=A0</div><= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"auto"><div dir= =3D"auto">Warner</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></d= iv><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_= quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,= 204);padding-left:1ex"> -- <br> Cheers,<br> Cy Schubert <<a href=3D"mailto:Cy.Schubert@cschubert.com" rel=3D"norefer= rer" target=3D"_blank">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" rel=3D"noreferrer" target=3D"_blank">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> </blockquote></div></div> --00000000000007e54f060a9eeacb--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrHMT88s1Zem-_N7Jkd-M2DgG_akwQqCQdvmggC70kkog>