namespace issues with old C headers

[David Schultz]

Thus spake Benjamin Kosnik <bkoz@redhat.com>:
> Sadly, in light of the above, I'd suggest people not mix C99 and C++
> math code.
> 
> >If you look at <cmath>, you'll see why this is a problem.  Here
> >are some possible solutions:
> >
> >(A)	Don't play tricks with C99 macros in <cmath>.  I think
> >	this approach would be fine by the C++ standard, but
> >	someone with a copy should check.
> 
> See above.
> 
> >(B)	Ameliorate the problem by getting rid of promiscuous
> >	includes of <cmath> in other headers.
> 
> This should be attempted, just because nobody likes profligate includes.
> 
> >(C)	Change <math.h> to redefine macros even if it has already
> >	been included earlier.  This is a kludge, and I'd rather
> >	not have to do it.
> 
> See above.

Your reasoning makes sense, so unless there's something we haven't
thought of, there may not be a good solution.  I think doing (B)
above would be sufficient to unbreak the programs I broke by
adding C99 support to FreeBSD's math.h.  ;-)  I'm perfectly happy
to declare that anyone who includes both <math.h> and <cmath>
deserves whatever they get, but I'm not so happy to declare the
same if they instead include <locale> and <math.h> together.

The way I would go about doing this is to create a <_cmath> header
that places all of the appropriate symbols in the __cmath
namespace.  Then <cmath> need only include <_cmath>, undef the C99
macros, and export the symbols in the std namespace.  Other
headers needing math functions can use the __cmath versions.
Now you're going to ask me for patches, aren't you?