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

On 20 Nov 2023, at 04:15, 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.

You mean __XSTRING; __CONCAT is to __XSTRING what __CONCAT1 is to __STRING,
confusingly (though __CONCAT1 is unused except for implementing __CONCAT).

Jess

> 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
>