Le 23 déc. 04, à 00:26, Tom Lane a écrit :
=?ISO-8859-1?Q?R=E9mi_Zara?= <[EMAIL PROTECTED]> 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/
smime.p7s
Description: S/MIME cryptographic signature
