Re: NaN/Inf fix for ECPG
От | Rémi Zara |
---|---|
Тема | Re: NaN/Inf fix for ECPG |
Дата | |
Msg-id | 0A033239-4803-4D6B-A7CD-3FC75F8CD46D@mac.com обсуждение исходный текст |
Ответ на | Re: NaN/Inf fix for ECPG (Boszormenyi Zoltan <zb@cybertec.at>) |
Список | pgsql-hackers |
Le 25 févr. 2010 à 11:26, Boszormenyi Zoltan a écrit : > > NAN on NetBSD/x86-64 is defined as: > > extern const union __float_u __nanf; > #define NAN __nanf.__val > Same here: math.h:extern const union __float_u __nanf; math.h:#define NAN __nanf.__val > I would guess that it's similar on mips. Is is possible that > NetBSD/mips has a conversion bug? > > What I don't get is that the code I used in ECPG and in this > test code is the same as in src/backend/utils/adt/float.c. E.g.: > float8in sees "NaN" -> value will be (double)NAN > float8out sees isnan(value) -> outputs "NaN" string > > Can someone shed some light on why the backend > doesn't get the problem as above? :-( > > As Rémi says, isnan((double)(0.0 / 0.0)) == true for him. > Michael: IIRC, IEEE754 explicit about that the (0.0/0.0) division > produces NaN. How about doing it explicitely in ECPG? > > Rémi: please, run this code to confirm the above? > bash-4.1$ gcc -Wall -o nantest1 nantest1.c -lm bash-4.1$ ./nantest1 computed NAN 1 0 defined INFINITY 0 1 Regards, Rémi Zara
В списке pgsql-hackers по дате отправления: