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.
