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

[David Edelsohn <dje dot gcc at gmail dot com>]

On Thu, Apr 21, 2016 at 8:33 AM, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
> 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.

C++ headers cannot be included before GCC headers because some
systems, such as AIX, depend on macros defined in GCC system.h -- the
behavior of the system headers depend on definitions set by GCC.  The
C++ headers would pull in system headers prior to the GCC headers and
cause build failures.

Thanks, David