Re: strtod bugs

[Jim Meyering]

Eric Blake <address@hidden> wrote:

> According to Jim Meyering on 3/30/2008 7:28 AM:
> | Eric Blake <address@hidden> wrote:
> | ...
> |> Therefore, I'm asking for opinions - should I apply this patch as is, to
> |
> | Seems fine that you've applied it, except for a new failure
> | in coreutils' running of the gnulib strtod test.  E.g.,
> |
> |     test-strtod.c:544: assertion failed
> |     test-strtod.c:592: assertion failed
> |     test-strtod.c:635: assertion failed
>
> All three of these assertions deal with parsing the end pointer on "nan"
> vs. "-nan".

In my copy of test-strtod.c, they're all comparing sign bits:

    ASSERT (signbit (result1) != signbit (result2));

This sort of mix-up is a good argument for not changing
line numbers when we add the two prefix lines:

    /* -*- buffer-read-only: t -*- vi: set ro: */
    /* DO NOT EDIT! GENERATED AUTOMATICALLY! */

> Which libc are you using?

    rawhide's glibc-2.7.90-13.x86_64
    debian unstable's libc6 2.7-10

When I run the tests on a 32-bit system with ubuntu's
2.7-9ubuntu2, I get even more failures:

    PASS: test-string
    test-strtod.c:285: assertion failed
    test-strtod.c:371: assertion failed
    test-strtod.c:480: assertion failed
    test-strtod.c:544: assertion failed
    test-strtod.c:592: assertion failed
    test-strtod.c:635: assertion failed
    test-strtod.c:816: assertion failed

> I'm assuming that the minimal
> tests in strtod.m4 didn't find anything wrong with your libc?

Right:

    $ grep STRTOD config.status
    S["GNULIB_STRTOD"]="1"
    S["HAVE_STRTOD"]="1"
    S["REPLACE_STRTOD"]="0"

> http://buildbot.proulx.com:9000/i686%20gnu-linux%20full/builds/524/step-test/0
> |
>
> This shows some different failures, such as on not leaving errno unchanged
> for "-0".  Also something I should add to strtod.m4.