> >> 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).
That worked. Endianness shouldn't be a big problem, because win32
doesn't run on more than one endianness....
I'll incorporate this in a new version of the patch - just need to
figure out what to do about _dosmaperror() and the cbrt() issue as well
:-)
//Magnus