namespace issues with old C headers

[Loren James Rittle]

In article <20030403043520.GA24413@HAL9000.homeunix.com> you write:

> Now you're going to ask me for patches, aren't you?

Hey David Schultz,

(For the record, addressing a question from your first e-mail in this
 thread, glibc does fail the test that you are proposing to fix for
 FreeBSD.  This should not dissuade you from sending patches; I will
 review, approve and commit any patches that help FreeBSD yet are
 general and in line with Benjamin's thoughts.)

I already owe the gcc-side a patch for a problem seen on daily ref5
bootstraps after your C99 patches went into FreeBSD 5.  I haven't
worked on it yet since there was an open discussion on how to best
handle it.  As the primary author/committer of the C99 stuff in
FreeBSD system headers how about commenting on this issue:

`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:

       -ansi  Support all ANSI standard C programs.
	[...]
              The `-ansi' option does not cause non-ANSI programs  to  be  re-
              jected gratuitously.  For that, `-pedantic' is required in addi-
              tion to `-ansi'.

              The preprocessor predefines a macro __STRICT_ANSI__ when you use
              the `-ansi' option.  Some header files may notice this macro and
              refrain from declaring certain  functions  or  defining  certain
              macros that the ANSI standard doesn't call for; this is to avoid
              interfering with any programs that might  use  these  names  for
              other things.

However, the second quoted clause which followed directly after the
first quoted clause is what makes me now think that my plan (b) is
absolutely correct if somewhat tedious.  As Benjamin observed, it must
be done in a way that *doesn't* change the link-ABI.  It may change
the visibility of some parts of the link-ABI, but that was the entire
point of adding -ansi...

Regards,
Loren