Thread: float8 errors in HEAD...

I'm not sure if the regression tests haven't been updated or if
there's a change, but I'm getting this on a recent FreeBSD machine
with gcc 3.2.2.  Any ideas?  -sc


*** ./expected/float8-small-is-zero.out Tue Mar 11 13:01:33 2003
--- ./results/float8.out        Tue May  6 22:13:17 2003
***************
*** 274,280 ****
--- 274,282 ----
  INSERT INTO FLOAT8_TBL(f1) VALUES ('-10e400');
  ERROR:  Input '-10e400' is out of range for float8
  INSERT INTO FLOAT8_TBL(f1) VALUES ('10e-400');
+ ERROR:  Input '10e-400' is out of range for float8
  INSERT INTO FLOAT8_TBL(f1) VALUES ('-10e-400');
+ ERROR:  Input '-10e-400' is out of range for float8
  -- maintain external table consistency across platforms
  -- delete all values and reinsert well-behaved ones
  DELETE FROM FLOAT8_TBL;

======================================================================

--
Sean Chittenden

Sean Chittenden <sean@chittenden.org> writes:
> I'm not sure if the regression tests haven't been updated or if
> there's a change, but I'm getting this on a recent FreeBSD machine
> with gcc 3.2.2.  Any ideas?  -sc

Apparently your machine now matches the "standard" float8.out.

Do you know how to tell the difference between what you have and
the freebsd releases that produce the small-is-zero results?

If we don't know how to distinguish them, the only fallback I can
see is to treat the small-is-zero case as a locale variant, which
would mean we'd accept it as legitimate behavior on any platform.
I'd rather not do that...

            regards, tom lane

> > I'm not sure if the regression tests haven't been updated or if
> > there's a change, but I'm getting this on a recent FreeBSD machine
> > with gcc 3.2.2.  Any ideas?  -sc
>
> Apparently your machine now matches the "standard" float8.out.

*nods* The old routines were pretty old and gcc 2.95.4 produced broken
code for anything higher than -O0.  :( The newer routines were
recently imported and work properly, however, resulting in the lack of
brokenness.

http://netlib.bell-labs.com/netlib/fp/

> Do you know how to tell the difference between what you have and the
> freebsd releases that produce the small-is-zero results?

I don't know in what context you're talking about detecting this, but,
how's this?

#ifdef __FreeBSD_version > 500112
/* Working strtod() */
#else
/* Broken code strtod() */
#endif

-sc

--
Sean Chittenden

Sean Chittenden <sean@chittenden.org> writes:
>> Do you know how to tell the difference between what you have and the
>> freebsd releases that produce the small-is-zero results?

> I don't know in what context you're talking about detecting this, but,
> how's this?

We need to know it in the context of the pg_regress shell script, which
at the moment wants to make those decisions on the basis of the "host"
string determined by configure.  Unless the OS version number from uname
is different between the fixed and broken releases, we gotta problem ...

            regards, tom lane

> >> Do you know how to tell the difference between what you have and
> >> the freebsd releases that produce the small-is-zero results?
>
> > I don't know in what context you're talking about detecting this,
> > but, how's this?
>
> We need to know it in the context of the pg_regress shell script,
> which at the moment wants to make those decisions on the basis of
> the "host" string determined by configure.  Unless the OS version
> number from uname is different between the fixed and broken
> releases, we gotta problem ...

I don't know if there's a better way of doing this with an if, but:

case `uname` in
'FreeBSD')
        echo "Using FreeBSD"
        if [ `sysctl -n kern.osreldate` -gt 500112 ]; then
                echo "Non-broken stdtod()"
        else
                echo "Broken stdtod()"
        fi
        ;;
*)
        echo "Not FreeBSD"
        ;;
esac

-sc

--
Sean Chittenden