|
From: | Pádraig Brady |
Subject: | bug#23537: timeout test gets false-positive for duration of -1.189731495357231765e+4932 |
Date: | Sun, 15 May 2016 12:21:08 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |