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

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
>