Re: Building with Visual C++
От | Tom Lane |
---|---|
Тема | Re: Building with Visual C++ |
Дата | |
Msg-id | 2263.1145893894@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Building with Visual C++ ("Magnus Hagander" <mha@sollentuna.net>) |
Список | pgsql-patches |
"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
В списке pgsql-patches по дате отправления: