Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-patches by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group