Le 23 déc. 04, à 00:26, Tom Lane a écrit :
> Rémi Zara <remi_zara@mac.com> writes:
>> --- src/test/regress/resultmap.orig 2004-10-04
>> 16:42:47.000000000=20
>> +0200
>> +++ src/test/regress/resultmap 2004-12-22 23:27:51.000000000 +0100
>> @@ -3,6 +3,7 @@
>> float8/i.86-.*-freebsd[234]=float8-small-is-zero
>> float8/i.86-.*-openbsd=float8-small-is-zero
>> float8/i.86-.*-netbsd=float8-small-is-zero
>> +float8/m68k-.*-netbsd=float8-small-is-zero
>> float8/.*-qnx=float8-exp-three-digits
>> float8/i.86-pc-mingw32=float8-exp-three-digits-win32
>> float8/i.86-pc-cygwin=float8-small-is-zero
>
> Looks reasonable to me --- why do you call it only a "semi" fix
Because strtod really should underflow, so there seems to be a bug in
NetBSD's strtod.
So this is just accepting the bug, not correcting it :)
> I wonder whether we oughtn't remove the i.86- part from the patterns
> for the BSDen, ie, assume they will have this behavior on all hardware
> not just Intel.
From pgbuildfarm, it seems that openBSD sparc64 does not exhibit the
problem (it's not part of resultmap, and passes the float8 test).
Regards,
Rémi Zara
--
Rémi Zara
http://www.remi-zara.net/
