From: | Rémi Zara <remi_zara(at)mac(dot)com> |
---|---|
To: | Boszormenyi Zoltan <zb(at)cybertec(dot)at> |
Cc: | Michael Meskes <meskes(at)postgresql(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: NaN/Inf fix for ECPG |
Date: | 2010-02-25 10:38:24 |
Message-ID: | 0A033239-4803-4D6B-A7CD-3FC75F8CD46D@mac.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2010-02-25 10:48:51 | Re: testing cvs HEAD - HS/SR - xlog timeline 0 pg_xlogfile_name_offset |
Previous Message | Boszormenyi Zoltan | 2010-02-25 10:26:12 | Re: NaN/Inf fix for ECPG |