Re: Some K&R support to be removed from sys/cdefs.h

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
>