GCC 6 symbol poisoning and c++ header usage is fragile

[Szabolcs Nagy]

On 21/04/16 12:52, Jonathan Wakely wrote:
> On 21 April 2016 at 12:11, Szabolcs Nagy wrote:
>> the root cause is c++: c++ headers include random libc headers with
>> _GNU_SOURCE ftm so all sorts of unexpected symbols are defined/declared.
> 
> Yes, I'd really like to be able to stop defining _GNU_SOURCE
> unconditionally. It needs some libstdc++ and glibc changes for that to
> happen, I'll be looking at it for gcc 7.
> 
> 
>> since it's unlikely the c++ standard gets fixed (to properly specify
>> the namespace rules)
> 
> Fixed how? What's wrong with the rules? (I'd like to understand what's
> wrong here before I try to change anything, and I don't understand the
> comment above).
> 

posix has "namespace rules" specifying what symbols
are reserved for the implementation when certain
headers are included.
(it's not entirely trivial, i have a collected list
http://port70.net/~nsz/c/posix/reserved.txt
http://port70.net/~nsz/c/posix/README.txt
i use for testing musl headers, glibc also does
such namespace checks.)

e.g. the declared function names in a header are
reserved to be defined as macros.

c++ does not specify how its headers interact with
posix headers except for a few c standard headers
where it requires no macro definition for functions
(and imposes some other requirements on the libc
like being valid c++ syntax, using extern "C" where
appropriate etc).

so from a libc implementor's point of view, including
libc headers into c++ code is undefined behaivour
(neither posix nor c++ specifies what should happen).
without a specification libc headers just piling
#ifdef __cplusplus hacks when ppl run into problems.

e.g. c++ code uses ::pthread_equal(a,b), but musl used
a macro for pthread_equal (the only sensible
implementation is (a)==(b), this has to be suppressed
for c++, which now uses an extern call to do the
same), i'm also pretty sure a large number of c++
code would break if unistd.h defined "read", "write",
"link" etc as macros, since these are often used as
method names in c++, but this would be a conforming
libc implementation.