--- Begin Message ---
|
Subject: |
timeout test gets false-positive for duration of -1.189731495357231765e+4932 |
|
Date: |
Sat, 14 May 2016 10:09:19 -0700 |
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:
$ 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.
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#23537: timeout test gets false-positive for duration of -1.189731495357231765e+4932 |
|
Date: |
Sun, 15 May 2016 08:51:58 -0700 |
tags 23537 notabug
stop
On Sun, May 15, 2016 at 8:06 AM, Jim Meyering <address@hidden> wrote:
> On Sun, May 15, 2016 at 4:21 AM, Pádraig Brady <address@hidden> wrote:
>> Has up to date centos6 the bug?
>> I didn't see it with glibc-2.12-1.166.el6_7.7.x86_64
>
> Yes. I am surprised that you don't see it and I do:
>
> $ rpm -q glibc
> glibc-2.12-1.166.el6_7.7.x86_64
> $ src/timeout 0.1 sleep 1.189731495357231765e+4932; echo $?
> 0
Pádraig guessed (correctly) that I'd updated coreutils' gnulib to
include a temporarily buggy xstrdod
(811b09243ca01827469827bf0973728a8619d249), but not yet past the fix
from a day or so later.
So this was all a false alert.
--- End Message ---