Eric Blake <[EMAIL PROTECTED]> wrote:
> According to Jim Meyering on 3/30/2008 7:28 AM:
> | Eric Blake <[EMAIL PROTECTED]> 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.
