On Wed, 7 Dec 2022, 23:13 Tom Kacvinsky via Gcc-help, <gcc-help@gcc.gnu.org>
wrote:

> Hi,
>
> I ran into a rather interesting issue today.  I noticed that if I run
> (with GCC 12.1)
>
> gcc -x c -std=c17 -dM -E foo.c
>
> where foo.c is simply
>
> #include <features.h>
>
> I don't get any of the XOPEN, POSIX or BSD defines that features.h would
> typically
> set based on -D options passed to the compiler.
>
> However, if I run
>
> gcc -x c++ -std=c++17 -dM -E foo.c
>
> I get definitions like
>
> #define _XOPEN_SOURCE 700.
>
> I find this curious - I thought compilers were supposed to be OS standards
> agnostic
> (but obviously not language standards agnostic).
>
> I am using a glibc 2.17 system, if that makes any difference.  I don't see
> anything in
> features.h that would indicate _XOPEN_SOURCE should be defined if the
> compiler
> is a C++ compiler conforming to the C++17 standard (for instance).
>
> Any ideas as to what is going on here?  Is this expected behavior, as in
> something in
> the C++ standard I am unaware of, or is it a bug?
>

It's expected but nothing to do with the standard. The C++ standard has
nothing to say about POSIX macros.

On glibc Linux systems libstdc++ depends on some gnu extensions in glibc.
In order to ensure that those extensions can be used, g++ automatically
defines _GNU_SOURCE. That causes glibc to define all POSIX APIs, including
those macros.





> Thanks,
>
> Tom
>