This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]