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

On Mon, Nov 20, 2023 at 9:14 AM 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 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...
>

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275221 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=0
>>
>