"Magnus Hagander" <mha@sollentuna.net> writes:
>> If they're going to be that anally uncooperative, why don't
>> they have the required-by-C99-spec macro for NAN? Or at
>> least some well-defined way to generate a NaN?
> They do have one way that's documented on MSDN, which is:
> unsigned long nan[2]={0xffffffff, 0x7fffffff};
> double g = *( double* )nan;
> I thought that was even uglier ;-), but I can change it to use that on
> win32 if you prefer it?
Count on MSFT to violate the spec and be incredibly ugly and unportable
all at the same time.
How about
#if defined(WIN32) && !defined(NAN)
static const uint32 nan[2] ...
#define NAN (*(const double *) nan)
#endif
somewhere near the top of float.c (after including <math.h>, which is
what's supposed to define NAN). There doesn't seem to be much we can do
about the endianness assumption in their hack, but at least we can avoid
the assumption about sizeof(long).
regards, tom lane
