> >> 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


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not

Reply via email to