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
