Re: Building with Visual C++

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Magnus Hagander" <mha(at)sollentuna(dot)net>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: Building with Visual C++
Date: 2006-04-24 15:51:34
Message-ID: 2263.1145893894@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

"Magnus Hagander" <mha(at)sollentuna(dot)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

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Magnus Hagander 2006-04-24 19:48:07 Re: Building with Visual C++
Previous Message Magnus Hagander 2006-04-24 07:40:23 Re: Building with Visual C++