Re: NaN/Inf fix for ECPG

Rémi Zara <remi_zara@mac.com>

From: Rémi Zara <remi_zara@mac.com>
To: Boszormenyi Zoltan <zb@cybertec.at>
Cc: Michael Meskes <meskes@postgresql.org>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2010-02-25T10:38:24Z
Lists: 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