This is the mail archive of the
mailing list for the GCC project.
Re: GCC 6 symbol poisoning and c++ header usage is fragile
- From: Joel Sherrill <joel dot sherrill at oarcorp dot com>
- To: Jonathan Wakely <jwakely dot gcc at gmail dot com>, Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, nd <nd at arm dot com>, Rich Felker <dalias at libc dot org>, Michael Matz <matz at suse dot de>
- Date: Thu, 21 Apr 2016 09:32:04 -0500
- Subject: Re: GCC 6 symbol poisoning and c++ header usage is fragile
- Authentication-results: sourceware.org; auth=none
- References: <5718B57D dot 1000501 at arm dot com> <CAH6eHdRG-vRp-fEZb8=KbzMUhsok6AR7VekNa=1CQyBvMjc4kQ at mail dot gmail dot com> <5718C8AA dot 7020703 at arm dot com> <CAH6eHdR7+LsXCMHkM_5M2spGQpOV=yS-LSYKamFDnY0XCXsBww at mail dot gmail dot com>
On 4/21/2016 8:20 AM, Jonathan Wakely wrote:
On 21 April 2016 at 13:33, Szabolcs Nagy 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
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
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
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
Gotcha, I understand what you mean now, thanks.
Those rules belong in a POSIX binding for C++, not in the C++
standard, but unfortunately the group working on that has been
inactive for some time.
(In the absence of an official binding, I think a reasonable rule that
would work for most sane C++ programs would be to say any name in
ALL_CAPS and any name using the ^_[_[:upper:]].* reserved namespace
can be a macro, but other names such as "read", "write", and "link"
must not be defined as macros by libc headers. Maybe it would be good
to come up with a set of rules for glibc and musl to agree on, if no
official POSIX C++ binding is going to happen.)
newlib should also be on this list. I know the RTEMS community
cares about being proper per POSIX and I would expect the Cygwin
community to feel the same way.
Other than inspection, what can be done to find violations?
Even if I fix libstdc++ to not require _GNU_SOURCE that won't make the
problem go away, because a user could still do:
and if "read" is a macro that will break the declaration of std::istream::read.
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherrill@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35806
Support Available (256) 722-9985