PATCH: libstdc++/7680 (related to RFC posted last week)

[Benjamin Kosnik]

>While looking over tweaks for the patch to mirror system header
>visibility (work stalled since the FreeBSD 5 reference machines were
>broken this week), I looked at libstdc++/7680 again (related problem,
>but my efforts last Friday didn't cover it).  That PR is against
>FreeBSD in particular but I seem to recall similar issues on some
>other ports.  How much trouble am I in if I apply this patch? ;-)

Yes. I've been thinking that this same approach would work on linux...

>(This one only covers C99 float transcendentals since that is the
>sticky issue for FreeBSD on the PR of interest and that is all I can
>test on FreeBSD 4, another patch could cover C99 long double
>transcendentals and most of my other cases of the first patch I posted
>last week regarding C99 support for FreeBSD 5.  Most of the other
>things that system vendors might like to optionally hide, which are
>keyed off macros, and that we might like to use, fall into this camp
>and are supported by this technique.)

Yes. The wchar_t bits in particular....

>Ports that define neither of:
>_GLIBCPP_USE_C99_FLOAT_TRANSCENDENTALS_CHECK
>_GLIBCPP_USE_C99_FLOAT_TRANSCENDENTALS_DYNAMIC
>see only an extra level of namespace monkeying (well, since all this
>is for internal library implementation, no one really sees it).
>
>Ports that define _GLIBCPP_USE_C99_FLOAT_TRANSCENDENTALS_CHECK to be 1
>get a check which ensures that the system headers are consistent with
>our requirements (I assume below that only ports expected to have
>clean system headers would throw the switch, but negating it by
>default would be interesting as well IMHO).  Ports may define
>_GLIBCPP_USE_C99_FLOAT_TRANSCENDENTALS_DYNAMIC to map to 0 only when
>macros are exposing proper support from system headers (note the
>negative logic system which removes the crazy !define(X) || X construct).
>
>The number of gcc switches and standard-dictated macros that affect
>this space is probably enumerable, yet an autoconf-based solution
>seems elusive.  If this technique is OK by fellow library maintainers,
>then I shall redo all my outstanding work from last week into this
>form.  I will also look for discard PRs that might benefit from this
>technique.  I can at least work with a primary port maintainer to help
>them improve the situation they see in this area once the infrastructure
>is in place.

This technique seems fine to me. The PR search would be nice, of course,
and appreciated. 

Your namespace usage is fine to me. We seem to be heading in the
direction of multiple implementation namespaces, which I think is a good
idea as long as we all agree what goes where. I did think that all
__gnu_cxx bits were private already though. Would this imply that
__gnu_cxx is not private? This is not a serious objection, but just a
comment that we might want to step back a bit and think about how we are
using namespaces and what the plan is for the future so that people
don't get super confused.

There is 

__gnu_cxx
__gnu_cxx_private
__gnu_cxx_test

This doesn't seem so bad, I guess. What do you think?

>(BTW, spot checked, full testing over weekend now that reference
>FreeBSD machines operational again.  Yup, the new test case fails
>without the patch and passes with the patch.)

Personally, any patch with a comment this funny should just go in
straight away.

Gaby's been at ACCU and the standards meeting all week with limited
connectivity, so let's give him a chance to get back up to speed.

best,
benjamin