This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: G++ defining _GNU_SOURCE
On 06-Jun-2001, Nathan Sidwell <nathan@codesourcery.com> wrote:
>
> Here is my recollection of the problem.
>
> On linux (at least) _GNU_SOURCE needs to be #defined from the start because the
> user can write a program like
> #include <stdio.h> // non-libstdc++ header
> #include <iostream> // libstdc++ header
>
> Both these includes wind up #including the idempotent /usr/include/features.h
> which uses _GNU_SOURCE to turn on various bit'n'bobs that libstdc++
> needs/expects.
Defining _GNU_SOURCE even when -ansi is specified is a bug, isn't it?
It will break standard-conforming programs that happen to use the
same identifiers that _GNU_SOURCE enables. If libstdc++ requires that
_GNU_SOURCE be defined, then that is a bug in libstdc++, and ought to
be fixed.
I haven't looked at the libstdc++ source, so I could be way off here, but
I think it could perhaps be fixed, at the cost of efficiency, by making all
the libstdc++ usages of non-standard identifiers that might invade the
user's namespaces go via non-inline wrapper functions;
these wrapper functions would have names that don't invade any of the
user's namespaces, and would be defined in libstdc++ in .cc files.
(It's OK to define _GNU_SOURCE when compiling the .cc files in libstdc++;
defining _GNU_SOURCE when compiling the user's .cc files is what causes
problems.)
Alternatively, glibc could be modified to define alternative versions
of all of these identifiers that start with `__', and libstdc++ could use
those versions.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.