This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 6 symbol poisoning and c++ header usage is fragile
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: Joel Sherrill <joel dot sherrill at oarcorp dot com>
- Cc: Szabolcs Nagy <szabolcs dot nagy at arm dot com>, "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 16:57:53 +0100
- 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> <5718E464 dot 6000505 at oarcorp dot com>
On 21 April 2016 at 15:32, Joel Sherrill wrote:
>> 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.
Yes, newlib should on the list too - I thought of newlib but then
thought of something else and forgot to add it!
> Other than inspection, what can be done to find violations?
I once tried to write a gcc plugin that would check all names defined
by libstdc++ and ensure they were either in the reserved namespace, or
were in a whitelist of allowed names defined by the standard (such as
"istream" and "read"). It didn't work because gcc plugins don't run
early enough, so macros and uninstantiated templates are never seen by
the plugin.
I think it would be possible to write something using libclang that
would check for violations of that kind of rule, but I don't know how
to do that.