Re: strtod bugs

[Bruno Haible]

Eric Blake wrote:
> |  1) POSIX says that <math.h> defines the macro NAN, but also says that it
> |     expands into a constant expression. We cannot guarantee that. Therefore
> |     is it better to define the macro or not?
> 
> Well, I did document in doc/posix-functions/math.texi that NAN might not
> be constant

Yes, it's correct to document this, if we cannot fulfill POSIX entirely.

> Were you planning on backing out the math.in.h changes?

It depends on your vote... If you say no, then no.


> point to nan.h instead?)

nan.h lives in tests/, since for it to be usable in lib/ one additionally
needs to use 'inline' or similar.


> |  2) You make use of this macro also where a 'double' or 'long double' NaN
> |     is expected. We have enough portability problems with 'double' and
> |     'long double' alone; I'm not inclined to also get trapped by possible
> |     bugs in the conversion from float NaN to 'long double' NaN.
> 
> But are there any platforms out there that do the (implicit) cast wrong?

I don't even want to know. I've seen the definition of NaN on IA-64, and
don't want to think about how it's casted...

Also, it's too tempting to write

   sprintf (buf, "%Le foobar", NAN);

but then the argument being passed is actually a 'double', not a 'long double'.
Providing a macro NaNl() avoids this pitfall.

Bruno