Re: gets with C++ and GCC before 4.7

[Roland McGrath <roland at hack dot frob dot com>]

> I would love it if there was something like a _GLIBCXX_SOURCE macro
> that gave us the glibc extensions we rely on, so G++ didn't need to
> define _GNU_SOURCE.  Currently we don't have that and not only would
> it probably make the glibc code messier [...]

Actually the structure of features.h is intended to make this sort of thing
fairly easy.  The actual declarations are already controlled by internal
macros, so features.h can consolidate all the hair of complex conditions
under which to enable sets of features.

> [...] but just adding it to glibc wouldn't help if a new glibc was used
> with an old GCC that still expected to be able to use _GNU_SOURCE to
> expose the required functionality.

We can potentially conditionalize on GCC version or suchlike as you
suggest.  But Joseph is certainly right that all this is lipstick on a pig.

libstdc++ really should never use the nonstandard public interfaces, since
it makes it impossible to have something like a pure POSIX C++ environment
for applications.  We really ought to coordinate on exactly which libc
interfaces libstdc++ needs to use in its user-visible headers.  That is,
tell us everything that's not strictly ISO C that you are using.  For C++
headers that are beyond the scope of what a purely portable C++ program
would use but are standard or de facto standard for C++ programs across all
POSIX systems, tell us everything that's not strictly POSIX C header
interfaces that you are using.  Then we can figure out how best to expose
what libstdc++ needs in ways that ensure a future glibc + future libstdc++
can give standards-compliant (or de facto portable) applications full
control over what goes into their :: and macro name spaces, as is already
the norm in the pure C world.

The GCC and/or glibc wikis may be good places to start collecting the
information.  When all the needs from the libstdc++ side are in a list,
then we feature-test name space nerds can cogitate about how best to meet
them on the glibc side.

If, once we see the scope of that work, it doesn't seem too monumental to
do in the next glibc release cycle or two, then I think we'd be better off
not doing a half-measure like the _GLIBCXX_SOURCE idea.


Thanks,
Roland