[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: strtod bugs
From: |
Bruno Haible |
Subject: |
Re: strtod bugs |
Date: |
Wed, 2 Apr 2008 03:45:05 +0200 |
User-agent: |
KMail/1.5.4 |
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