GNU bug report logs - #23537
timeout test gets false-positive for duration of -1.189731495357231765e+4932

Previous Next

Package: coreutils;

Reported by: Jim Meyering <jim <at> meyering.net>

Date: Sat, 14 May 2016 17:10:01 UTC

Severity: normal

Done: Jim Meyering <jim <at> meyering.net>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Pádraig Brady <P <at> draigBrady.com>
To: Jim Meyering <jim <at> meyering.net>, 23537 <at> debbugs.gnu.org
Subject: bug#23537: timeout test gets false-positive for duration of -1.189731495357231765e+4932
Date: Sun, 15 May 2016 12:21:08 +0100
On 14/05/16 18:09, Jim Meyering wrote:
> On systems with recent glibc, this abuse of timeout elicits the expected error:
>
>    $ src/timeout -- -1.189731495357231765e+4932 sleep 0
>    src/timeout: invalid time interval ‘-1.189731495357231765e+4932’
>    Try 'src/timeout --help' for more information.
>
> But with glibc-2.12's strtod, that input maps to a double-precision
> value of 0 rather than to -inf, so timeout does this:
>
>    $ src/timeout -- -1.189731495357231765e+4932 sleep 0; echo $?
>    0
>
> Similarly, the sleep.sh test fails because even without the leading "-",
> that number ($LDBL_MAX) maps to 0:
>

So the buggy strtod() is treating the overflow as underflow :(

>    $ src/timeout 0.1 sleep 1.189731495357231765e+4932; echo $?
>    0
>
> which causes two tests to fail:
>
>    tests/misc/timeout-parameters
>    tests/misc/sleep
>
> I see a couple of ways to avoid trouble.
> Perhaps the most general is to make gnulib's strtod module detect and
> compensate for these errors.
> But that's CentOS6-era glibc, so maybe not worth it for such a corner case.

Has up to date centos6 the bug?
I didn't see it with glibc-2.12-1.166.el6_7.7.x86_64

cheers,
Pádraig.




This bug report was last modified 9 years and 66 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.