namespace issues with old C headers

[David Schultz]

Thus spake Loren James Rittle <rittle@latour.rsch.comm.mot.com>:
> `g++ -ansi' disables long long C99 support in FreeBSD system headers.
> 
> libstdc++-v3 likes to configure the state of long long support
> unconditionally.  FreeBSD system headers support `long long'
> conditionally.  I could (a) multilib the FreeBSD libstdc++-v3 port
> (groan, we have refrained from doing this and even figured out how to
> optionally support FreeBSD 4's thread model); (b) filter the C++
> namespace to match the dynamic configuration of the system headers but
> keep libstdc++-v3 link-ABI the same in all cases (i.e. the built C++
> library would always support all ABI entry points ala the system's
> libc but the user who added command line switches that limited the
> functionality of the system headers would see a similar reduction in
> C++ namespace exposure); (c) ask you to put a subtle change in the
> FreeBSD system headers before 5.1 actually ships that allows
> __LONG_LONG_SUPPORTED to be defined in more cases when the language is
> C++.
> 
> Before I do the work for (b) in a manner that supported FreeBSD but
> was also general for other ports that required the feature, could you
> confirm that (c) would not be honored?
> 
> BTW, someone quoted the first clause below from the gcc manual
> claiming that FreeBSD system headers were wrong w.r.t. -ansi:
[...]

It is my understanding that -ansi is supposed to cause *all*
conformant ANSI C programs to compile, which implies that there
should be no extensions polluting the namespace.  So FreeBSD's
headers seem to be doing the right thing for C, and I assume -ansi
means the same thing for C++ programs.  However, if you have a
good case for (c), i.e. if FreeBSD's headers are actually doing
the *wrong* thing for C++, the best place to take it is probably
standards@FreeBSD.ORG.  (I'm only responsible for some of the
'long double' work in FreeBSD, not 'long long', by the way.)

Otherwise, (b) sounds like the right thing to do, and it probably
needs to be done anyway.  Presently libstdc++ assumes that the
system libraries always look exactly as they did when configure
was run, but in fact there are many compile-time factors that can
affect the visibility of certain symbols.  Unfortunately, it may
not be possible to get all C library implementors to agree on a
convention for the macros that define what should be visible.
Libstdc++ could use a system-dependent header that defines (for
example) _GLIBCPP_USE_LONG_LONG when __LONG_LONG_SUPPORTED is
defined.  Of course, when the library itself is configured and
compiled, you need to leave out all namespace-restricting options.
There shouldn't be any further problems with ABI compatability,
because then they would be problems for the C library as well.