Re: namespace issues with old C headers

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

> I agree that none of my proposals were perfect; that is why I
> posted three of them.  Is Loren working on a patch other than the
> one he mentioned in this thread?

The patches I'm currently working on relate to system header name
visibility (i.e. as keyed off well-known, sometimes standard-defined,
macros) and mirroring same as best as possible in libstdc++-v3 for all
ports (my main port of interest is *-*-freebsd* but I'm trying for a
semi-generic solution).

Agreed, I don't think I'm solving the C99 / C++98 conflict issue under
discussion in this thread.  I think practical concerns are what drove
us to attempt to support as much of C99 as possible in libstdc++-v3
even if not encouraged by C++98.  If there are cases where a program
can't use the classic headers along with C++ headers, then IMHO it is
the job of our C++ library implementation to address the conflict.

The current remapping of C99 macros, which are unaddressed by C++98,
into std:: isn't driven by any standard.

Also, David, I'm confused.  Could you repost an exact test case that
now fails.  g++ with libstdc++-v3 built on ref5/beast after you
updated C99 stuff in the system headers appears to handle:

#include <cstdlib>
#include <cmath>
#include <math.h>

main()
{
  using namespace std;
  double a = 0.0;
  double b = NAN;
  double c = 1.0;

  if (FP_ZERO != fpclassify (a)) abort ();
  if (FP_NAN != fpclassify (b)) abort ();
  if (FP_NORMAL != fpclassify (c)) abort ();
}

For the moment, users attempting to compile code at the confluence of
C99 and C++98, will have to deal with adding the 'using namespace std'
or 'using std::fpclassify'.

Regards,
Loren