[PATCH] features.h: Fix -Wundef problems

[Stefan Tauner]

On Mon, 1 Dec 2025 16:49:45 +0100
Corinna Vinschen <vinschen@redhat.com> wrote:

> GLibc adds `defined', but retains the `(MACRO - 0)' expression, even
> today, 10 years later.  I didn't test it, but shouldn't we do the same?

Thanks for bringing this up. Initially I thought that this idiom is
just for very old compilers that do not replace undefined macros with
0. However, the real reason seems to be to allow for comparing macros
that *are* defined but without value. In such cases (MACRO - 0) decays
to -0 which still can be used as operand in a comparison while just
MACRO would decay to nil leading to syntax errors.

Since defining some of the macros in question without value is actually
legal and useful the first version of my patch breaks those. This is
for example the case for -D_XOPEN_SOURCE= (NB: the = is important.
Without it gcc defines the macro to 1(!)).

I also found some embarrassing copy and paste mistakes that I also
fixed.

Additionally, I have used the idiom for the usages of _FORTIFY_SOURCE
and __OPTIMIZE__ that did not have used it previously. __OPTIMIZE__ is
set by the compilers if optimization is enabled. gcc and clang set it
to 1 in that case regardless of the optimization level (including -Os
and -Og). The GCC documentation explicitly states that it is defined
with a value of 1.
_FORTIFY_SOURCE on the other hand is set by the user. GCC documentation
defines the legal values 1 to 3, inclusive. The current code would bail
out for "-D_FORTIFY_SOURCE=".
So arguably the idiom is overkill for those two but OTOH I don't see
any disadvantage either so I left them in for now.

V2 is attached.
-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-features.h-Fix-Wundef-problems.patch
Type: text/x-patch
Size: 5571 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/newlib/attachments/20251203/9c7671a9/attachment.bin>