GNU bug report logs - #7877
sleep takes undocumented hex args

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 7877 in the body.
You can then email your comments to 7877 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: jidanni <at> jidanni.org
To: bug-coreutils <at> gnu.org
Subject: sleep takes undocumented hex args
Date: Fri, 21 Jan 2011 07:31:18 +0800

The documentation doesn't say that one can also use hex args:
$ time /bin/sleep 0x10
real    0m16.007s
However not octal args:
$ time /bin/sleep 010
real    0m10.003s
Maybe say how too.

Message #8 received at 7877 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: jidanni <at> jidanni.org
Cc: 7877 <at> debbugs.gnu.org
Subject: Re: bug#7877: sleep takes undocumented hex args
Date: Fri, 21 Jan 2011 10:24:36 +0100

jidanni <at> jidanni.org wrote:
> The documentation doesn't say that one can also use hex args:
> $ time /bin/sleep 0x10
> real    0m16.007s
> However not octal args:
> $ time /bin/sleep 010
> real    0m10.003s

Interesting.  Thanks for the report.
That's an artifact of GNU sleep using strtod, which means "inf" and
"INFINITY" are also accepted:

    $ timeout 1 sleep inf
    [Exit 124]

My first reflex was to make sleep reject args like 0x... and inf.
However, that would mean duplicating the parsing that strtod does,
in order to detect-and-skip leading isspace and/or "+".

No one likes duplication, but in this case it's not so bad, and seems
better than documenting the "extension", so I wrote the patch:

From 2bf8d9172cf653b31c202f327b3cc6240acec867 Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering <at> redhat.com>
Date: Fri, 21 Jan 2011 09:56:15 +0100
Subject: [PATCH] sleep: do not accept "inf" or hexadecimal numbers like 0x10

* src/sleep.c (strtod_pre_filter): New function.
(main): Use it.
* tests/misc/sleep-hex: New file.  Test for the above change.
* tests/Makefile.am (TESTS): Add it.
Reported by Dan Jacobson in http://debbugs.gnu.org/7877
---
 src/sleep.c          |   20 +++++++++++++++++++-
 tests/Makefile.am    |    1 +
 tests/misc/sleep-hex |   37 +++++++++++++++++++++++++++++++++++++
 3 files changed, 57 insertions(+), 1 deletions(-)
 create mode 100755 tests/misc/sleep-hex

diff --git a/src/sleep.c b/src/sleep.c
index d32daa4..36ee271 100644
--- a/src/sleep.c
+++ b/src/sleep.c
@@ -96,6 +96,23 @@ apply_suffix (double *x, char suffix_char)
   return true;
 }

+/* strtod accepts strings like "INF" and "infinity" as well as
+   hexadecimal representations, but we'd rather not extend sleep
+   to accept such inputs, so reject them here.  Return false for
+   such otherwise-valid inputs to strtod and true otherwise.  */
+static bool
+strtod_pre_filter (char const *s)
+{
+  char const *p = s;
+  while (isspace (*p))
+    ++p;
+  if (*p == '+')
+    ++p;
+  if (*p == '0' && (p[1] == 'x' || p[1] == 'X'))
+    return false;
+  return ISDIGIT (*p) || *p == '.';
+}
+
 int
 main (int argc, char **argv)
 {
@@ -126,7 +143,8 @@ main (int argc, char **argv)
     {
       double s;
       const char *p;
-      if (! xstrtod (argv[i], &p, &s, c_strtod)
+      if (! strtod_pre_filter (argv[i])
+          || ! xstrtod (argv[i], &p, &s, c_strtod)
           /* Nonnegative interval.  */
           || ! (0 <= s)
           /* No extra chars after the number and an optional s,m,h,d char.  */
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 1e4e300..3d08a73 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -225,6 +225,7 @@ TESTS =						\
   misc/shred-passes				\
   misc/shred-remove				\
   misc/shuf					\
+  misc/sleep-hex				\
   misc/sort					\
   misc/sort-benchmark-random			\
   misc/sort-compress				\
diff --git a/tests/misc/sleep-hex b/tests/misc/sleep-hex
new file mode 100755
index 0000000..a60a009
--- /dev/null
+++ b/tests/misc/sleep-hex
@@ -0,0 +1,37 @@
+#!/bin/sh
+# Ensure that sleep rejects "inf", 0x10 etc.
+
+# Copyright (C) 2011 Free Software Foundation, Inc.
+
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+. "${srcdir=.}/init.sh"; path_prepend_ ../src
+print_ver_ sleep
+
+sleep 0		|| fail=1
+sleep +0	|| fail=1
+sleep +.001	|| fail=1
+sleep 0.001	|| fail=1
+sleep 1e-4	|| fail=1
+sleep +1E-4	|| fail=1
+
+# The following were all accepted by coreutils-8.9 and earlier.
+# Now, such arguments are rejected.
+sleep +0x10	&& fail=1
+sleep 0x10	&& fail=1
+sleep INF	&& fail=1
+sleep +INF	&& fail=1
+sleep infinity	&& fail=1
+
+Exit $fail
--
1.7.3.5

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: bug-coreutils <at> gnu.org
Subject: Re: bug#7877: sleep takes undocumented hex args
Date: Fri, 21 Jan 2011 10:29:47 +0000

On 21/01/11 09:24, Jim Meyering wrote:
> +    return false;
> +  return ISDIGIT (*p) || *p == '.';
> +}

looks good. Perhaps rename to c_strtod_pre_filter()
as I initially wondered why you hardcoded '.'

cheers,
Pádraig.

Message #14 received at 7877 <at> debbugs.gnu.org (full text, mbox):

From: "Voelker, Bernhard" <bernhard.voelker <at> siemens-enterprise.com>
To: Jim Meyering <jim <at> meyering.net>,
	"jidanni <at> jidanni.org" <jidanni <at> jidanni.org>
Cc: "7877 <at> debbugs.gnu.org" <7877 <at> debbugs.gnu.org>
Subject: RE: bug#7877: sleep takes undocumented hex args
Date: Fri, 21 Jan 2011 11:35:12 +0100

Jim Meyering wrote:
> That's an artifact of GNU sleep using strtod, which means "inf" and
> "INFINITY" are also accepted:
> 
>     $ timeout 1 sleep inf
>     [Exit 124]

what's wrong with `sleep inf`?

Have a nice day,
Berny

Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: bug-coreutils <at> gnu.org
Subject: Re: bug#7877: sleep takes undocumented hex args
Date: Fri, 21 Jan 2011 12:12:08 +0100

Pádraig Brady wrote:
> On 21/01/11 09:24, Jim Meyering wrote:
>> +    return false;
>> +  return ISDIGIT (*p) || *p == '.';
>> +}
>
> looks good. Perhaps rename to c_strtod_pre_filter()
> as I initially wondered why you hardcoded '.'

Good idea.  Done.  Thanks for the quick review.

Message #20 received at 7877 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: "Voelker\, Bernhard" <bernhard.voelker <at> siemens-enterprise.com>
Cc: "7877 <at> debbugs.gnu.org" <7877 <at> debbugs.gnu.org>,
	"jidanni <at> jidanni.org" <jidanni <at> jidanni.org>
Subject: Re: bug#7877: sleep takes undocumented hex args
Date: Fri, 21 Jan 2011 12:37:55 +0100

Voelker, Bernhard wrote:
> Jim Meyering wrote:
>> That's an artifact of GNU sleep using strtod, which means "inf" and
>> "INFINITY" are also accepted:
>>
>>     $ timeout 1 sleep inf
>>     [Exit 124]
>
> what's wrong with `sleep inf`?

Hi Volker,

There's nothing terribly _wrong_ with it, but I am inclined not to
add the feature for the same reason I don't want to simply document
that sleep accepts 0x10 and treats it like "16": those are incidental
implementation details.  Once we document such a thing, we then commit to
ensuring it works everywhere, and in a sense encourage people to use the
"feature".  However, officially supporting "inf" doesn't gain much, yet
imposes a portability burden: does every strtod implementation convert
"inf" to something reasonable?  I doubt it.

If you want to sleep for a long time, you can use
sleep $(echo 2^32|bc) or sleep 999999d.

If you're worried that 2700 years is not enough ;-), use this:

    while :; do sleep 99d || break; done

Message #23 received at 7877 <at> debbugs.gnu.org (full text, mbox):

From: jidanni <at> jidanni.org
To: jim <at> meyering.net
Cc: 7877 <at> debbugs.gnu.org, bernhard.voelker <at> siemens-enterprise.com
Subject: Re: bug#7877: sleep takes undocumented hex args
Date: Fri, 21 Jan 2011 20:48:14 +0800

You see I was trying to make very special arguments to sleep so that I
can make sure to kill the one I want
    pkill -u jidanni -fx sleep\ 000022
It is not clear if that will still work. Maybe the man/info page should
say a regexp that matches all valid args.

Message #26 received at 7877 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: jidanni <at> jidanni.org
Cc: 7877 <at> debbugs.gnu.org, bernhard.voelker <at> siemens-enterprise.com
Subject: Re: bug#7877: sleep takes undocumented hex args
Date: Fri, 21 Jan 2011 14:03:41 +0100

jidanni <at> jidanni.org wrote:
> You see I was trying to make very special arguments to sleep so that I
> can make sure to kill the one I want
>     pkill -u jidanni -fx sleep\ 000022
> It is not clear if that will still work.

With today's change using "sleep 000022" will
still act just like "sleep 22".

I could not change that (and would not want to!)
without breaking with years of tradition.

> Maybe the man/info page should
> say a regexp that matches all valid args.

It already describes the format pretty well,
mentioning "floating point" and the four suffixes.

Message #29 received at 7877 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: jidanni <at> jidanni.org
Cc: 7877 <at> debbugs.gnu.org, bernhard.voelker <at> siemens-enterprise.com
Subject: Re: bug#7877: sleep takes undocumented hex args
Date: Fri, 21 Jan 2011 14:05:41 +0100

jidanni <at> jidanni.org wrote:
> You see I was trying to make very special arguments to sleep so that I
> can make sure to kill the one I want
>     pkill -u jidanni -fx sleep\ 000022
> It is not clear if that will still work. Maybe the man/info page should
> say a regexp that matches all valid args.

BTW, reading the manual I spotted a small problem.
Here's the fix:

From 2e8de846204e36a5876d00605caf7457a79fb552 Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering <at> redhat.com>
Date: Fri, 21 Jan 2011 14:02:27 +0100
Subject: [PATCH] doc: fix wording in warning about potential conflict with built-in

* doc/coreutils.texi (mayConflictWithShellBuiltIn): Fix wording.
---
 doc/coreutils.texi |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 8a1b3b6..746ab8c 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -624,7 +624,7 @@ Common options
 @macro mayConflictWithShellBuiltIn{cmd}
 @cindex conflicts with shell built-ins
 @cindex built-in shell commands, conflicts with
-Due to shell aliases and built-in @command{\cmd\} command, using an
+Due to shell aliases and built-in @command{\cmd\} functions, using an
 unadorned @command{\cmd\} interactively or in a script may get you
 different functionality than that described here.  Invoke it via
 @command{env} (i.e., @code{env \cmd\ @dots{}}) to avoid interference
--
1.7.3.5

Message #32 received at 7877 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: jidanni <at> jidanni.org
Cc: 7877 <at> debbugs.gnu.org
Subject: Re: bug#7877: sleep takes undocumented hex args
Date: Fri, 21 Jan 2011 13:08:36 +0000

On 21/01/11 12:48, jidanni <at> jidanni.org wrote:
> You see I was trying to make very special arguments to sleep so that I
> can make sure to kill the one I want
>     pkill -u jidanni -fx sleep\ 000022
> It is not clear if that will still work. Maybe the man/info page should
> say a regexp that matches all valid args.

sleeps args are cumulative, so you can: sleep 0 0 0 0 22

Message #35 received at 7877 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: 7877 <at> debbugs.gnu.org, bernhard.voelker <at> siemens-enterprise.com,
	jidanni <at> jidanni.org
Subject: Re: bug#7877: sleep takes undocumented hex args
Date: Fri, 21 Jan 2011 07:51:42 -0700

[Message part 1 (text/plain, inline)]

On 01/21/2011 06:03 AM, Jim Meyering wrote:
> jidanni <at> jidanni.org wrote:
>> You see I was trying to make very special arguments to sleep so that I
>> can make sure to kill the one I want
>>     pkill -u jidanni -fx sleep\ 000022
>> It is not clear if that will still work.
> 
> With today's change using "sleep 000022" will
> still act just like "sleep 22".
> 
> I could not change that (and would not want to!)
> without breaking with years of tradition.
> 
>> Maybe the man/info page should
>> say a regexp that matches all valid args.
> 
> It already describes the format pretty well,
> mentioning "floating point" and the four suffixes.

Floating point literals include hex-floats, such as 0x1p1.  Does today's
added pre-filtering to reject 0x1 accidentally also reject hex-float
literals?  (It's a bit of a shame that when hex-floats were added that
strtod() was altered to accept hex-float literals but as a side effect
it also started accepting hexadecimal values without the p[+-]?[0-9]+
exponent suffix).

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #38 received at 7877 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Eric Blake <eblake <at> redhat.com>
Cc: 7877 <at> debbugs.gnu.org, bernhard.voelker <at> siemens-enterprise.com,
	jidanni <at> jidanni.org
Subject: Re: bug#7877: sleep takes undocumented hex args
Date: Fri, 21 Jan 2011 15:57:44 +0100

Eric Blake wrote:

> On 01/21/2011 06:03 AM, Jim Meyering wrote:
>> jidanni <at> jidanni.org wrote:
>>> You see I was trying to make very special arguments to sleep so that I
>>> can make sure to kill the one I want
>>>     pkill -u jidanni -fx sleep\ 000022
>>> It is not clear if that will still work.
>>
>> With today's change using "sleep 000022" will
>> still act just like "sleep 22".
>>
>> I could not change that (and would not want to!)
>> without breaking with years of tradition.
>>
>>> Maybe the man/info page should
>>> say a regexp that matches all valid args.
>>
>> It already describes the format pretty well,
>> mentioning "floating point" and the four suffixes.
>
> Floating point literals include hex-floats, such as 0x1p1.  Does today's
> added pre-filtering to reject 0x1 accidentally also reject hex-float
> literals?  (It's a bit of a shame that when hex-floats were added that
> strtod() was altered to accept hex-float literals but as a side effect
> it also started accepting hexadecimal values without the p[+-]?[0-9]+
> exponent suffix).

I see no significant utility in accepting hex floats.  Do you?
If you're concerned about errors in conversion or the efficiency
of the conversion process, then you probably don't want to use
the sleep command in the first place.

Message #41 received at 7877 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: 7877 <at> debbugs.gnu.org, bernhard.voelker <at> siemens-enterprise.com,
	jidanni <at> jidanni.org
Subject: Re: bug#7877: sleep takes undocumented hex args
Date: Fri, 21 Jan 2011 07:59:28 -0700

[Message part 1 (text/plain, inline)]

On 01/21/2011 07:57 AM, Jim Meyering wrote:
>> Floating point literals include hex-floats, such as 0x1p1.  Does today's
>> added pre-filtering to reject 0x1 accidentally also reject hex-float
>> literals?  (It's a bit of a shame that when hex-floats were added that
>> strtod() was altered to accept hex-float literals but as a side effect
>> it also started accepting hexadecimal values without the p[+-]?[0-9]+
>> exponent suffix).
> 
> I see no significant utility in accepting hex floats.  Do you?

No, and rejecting them is fine with me, although our documentation
should be tweaked to be clear that we don't accept _all_ floating point
literals, but just those with optional e[+-]?[0-9]+ suffix.

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #44 received at 7877 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jim Meyering <jim <at> meyering.net>
Cc: 7877 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#7877: sleep takes undocumented hex args
Date: Fri, 21 Jan 2011 11:07:35 -0800

On 01/21/2011 01:24 AM, Jim Meyering wrote:
> My first reflex was to make sleep reject args like 0x... and inf.

My reflex was just the opposite: why reject a notation
that might be useful?

Several other programs (printf, seq, sort, tail, plus many
other GNU programs) also use strtod or strtold.  If 'sleep' is
changed to reject hexadecimal and infinity, shouldn't they
be changed too, for consistency?

I expect it's better to leave these programs alone.  Not only
is this simpler, and a tiny bit cheaper at runtime, it's slightly
less likely to break existing usage.

Anyway, whatever we do, we should document it better.  To start the ball
rolling on that, I pushed the following change, which documents the
existing behavior.  We can change this if we change the behavior.

From df79069b2cfb8435e8b33693c9e03e8689b2659b Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert <at> cs.ucla.edu>
Date: Fri, 21 Jan 2011 10:59:32 -0800
Subject: [PATCH] manual: document floating point better

* doc/coreutils.texi (Floating point): New section.
(od invocation, tail invocation, sort invocation, printf invocation):
(sleep invocation, seq invocation): Refer and defer to it.  See
<http://lists.gnu.org/archive/html/bug-coreutils/2011-01/msg00031.html>.
---
 doc/coreutils.texi |   52 +++++++++++++++++++++++++++++++++++++++-------------
 1 files changed, 39 insertions(+), 13 deletions(-)

diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 8a1b3b6..926171c 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -217,6 +217,7 @@ Common Options
 * Exit status::                  Indicating program success or failure
 * Backup options::               Backup options
 * Block size::                   Block size
+* Floating point::               Floating point number representation
 * Signal specifications::        Specifying signals
 * Disambiguating names and IDs:: chgrp and chown owner and group syntax
 * Random sources::               Sources of random data
@@ -729,6 +730,7 @@ name.
 * Exit status::                 Indicating program success or failure.
 * Backup options::              -b -S, in some programs.
 * Block size::                  BLOCK_SIZE and --block-size, in some programs.
+* Floating point::              Floating point number representation.
 * Signal specifications::       Specifying signals using the --signal option.
 * Disambiguating names and IDs:: chgrp and chown owner and group syntax
 * Random sources::              --random-source, in some programs.
@@ -1011,6 +1013,34 @@ set.  The @option{-h} or @option{--human-readable} option is equivalent to
 @option{--block-size=human-readable}.  The @option{--si} option is
 equivalent to @option{--block-size=si}.
 
+@node Floating point
+@section Floating point numbers
+@cindex floating point
+@cindex IEEE floating point
+
+Commands that accept or produce floating point numbers employ the
+floating point representation of the underlying system, and suffer
+from rounding error, overflow, and similar floating-point issues.
+Almost all modern systems use IEEE-754 floating point, and it is
+typically portable to assume IEEE-754 behavior these days.  IEEE-754
+has positive and negative infinity, distinguishes positive from
+negative zero, and uses special values called NaNs to represent
+invalid computations such as dividing zero by itself.  For more
+information, please see David Goldberg's paper
+@uref{http://@/www.validlab.com/@/goldberg/@/paper.pdf, What Every
+Computer Scientist Should Know About Floating-Point Arithmetic}.
+
+@vindex LC_NUMERIC
+Commands that accept floating point numbers as options, operands or
+input use the standard C functions @code{strtod} and @code{strtold} to
+convert from text to floating point numbers.  These floating point
+numbers therefore can use scientific notation like @code{1.0e-34} and
+@code{-10e100}.  Modern C implementations also accept hexadecimal
+floating point numbers such as @code{-0x.ep-3}, which stands for
+@minus{}14/16 times @math{2^-3}, which equals @minus{}0.109375.  The
+@env{LC_NUMERIC} locale determines the decimal-point character.
+@xref{Parsing of Floats,,, libc, The GNU C Library Reference Manual}.
+
 @node Signal specifications
 @section Signal specifications
 @cindex signals, specifying
@@ -1880,7 +1910,7 @@ named character, ignoring high-order bit
 @item d
 signed decimal
 @item f
-floating point
+floating point (@pxref{Floating point})
 @item o
 octal
 @item u
@@ -2820,8 +2850,7 @@ During one iteration, every specified file is checked to see if it has
 changed size.
 Historical implementations of @command{tail} have required that
 @var{number} be an integer.  However, GNU @command{tail} accepts
-an arbitrary floating point number (using a period before any
-fractional digits).
+an arbitrary floating point number.  @xref{Floating point}.
 When @command{tail} uses inotify, this polling-related option is ignored.
 
 @itemx --pid=@var{pid}
@@ -3883,11 +3912,8 @@ the final result, after the throwing away.))
 @opindex --sort
 @cindex general numeric sort
 @vindex LC_NUMERIC
-Sort numerically, using the standard C function @code{strtold} to convert
-a prefix of each line to a long double-precision floating point number.
-This allows floating point numbers to be specified in scientific notation,
-like @code{1.0e-34} and @code{10e100}.
-The @env{LC_NUMERIC} locale determines the decimal-point character.
+Sort numerically, converting a prefix of each line to a long
+double-precision floating point number.  @xref{Floating point}.
 Do not report overflow, underflow, or conversion errors.
 Use the following collating sequence:
 
@@ -11209,6 +11235,7 @@ digits, but is printed according to the @env{LC_NUMERIC} category of the
 current locale.  For example, in a locale whose radix character is a
 comma, the command @samp{printf %g 3.14} outputs @samp{3,14} whereas
 the command @samp{printf %g 3,14} is an error.
+@xref{Floating point}.
 
 @kindex \@var{ooo}
 @kindex \x <at> var{hh}
@@ -15664,8 +15691,7 @@ days
 Historical implementations of @command{sleep} have required that
 @var{number} be an integer, and only accepted a single argument
 without a suffix.  However, GNU @command{sleep} accepts
-arbitrary floating point numbers (using a period before any fractional
-digits).
+arbitrary floating point numbers.  @xref{Floating point}.
 
 The only options are @option{--help} and @option{--version}.  @xref{Common
 options}.
@@ -15765,8 +15791,7 @@ When @var{increment} is not specified, it defaults to @samp{1},
 even when @var{first} is larger than @var{last}.
 @var{first} also defaults to @samp{1}.  So @code{seq 1} prints
 @samp{1}, but @code{seq 0} and @code{seq 10 5} produce no output.
-Floating-point numbers
-may be specified (using a period before any fractional digits).
+Floating-point numbers may be specified.  @xref{Floating point}.
 
 The program accepts the following options.  Also see @ref{Common options}.
 Options must precede operands.
@@ -15843,7 +15868,8 @@ of @code{%x}.
 
 On most systems, seq can produce whole-number output for values up to
 at least @math{2^{53}}.  Larger integers are approximated.  The details
-differ depending on your floating-point implementation, but a common
+differ depending on your floating-point implementation.
+@xref{Floating point}.  A common
 case is that @command{seq} works with integers through @math{2^{64}},
 and larger integers may not be numerically correct:
 
-- 
1.7.3

Message #49 received at 7877-done <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 7877-done <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#7877: sleep takes undocumented hex args
Date: Fri, 21 Jan 2011 20:28:56 +0100

Paul Eggert wrote:
> On 01/21/2011 01:24 AM, Jim Meyering wrote:
>> My first reflex was to make sleep reject args like 0x... and inf.
>
> My reflex was just the opposite: why reject a notation
> that might be useful?

I see that at least freebsd's /bin/sleep and the one from sunos 5.11
work just like the one from coreutils (without my proposed change)
in accepting e.g., 0x1 and inf.

netbsd's accepts 0x1 but not inf.
openbsd's accepts neither.

> Several other programs (printf, seq, sort, tail, plus many
> other GNU programs) also use strtod or strtold.  If 'sleep' is
> changed to reject hexadecimal and infinity, shouldn't they
> be changed too, for consistency?
>
> I expect it's better to leave these programs alone.  Not only
> is this simpler, and a tiny bit cheaper at runtime, it's slightly
> less likely to break existing usage.
>
> Anyway, whatever we do, we should document it better.  To start the ball
> rolling on that, I pushed the following change, which documents the
> existing behavior.  We can change this if we change the behavior.

The above, plus your added documentation are good enough
reasons to leave sleep as-is.

Thanks.

Message #52 received at 7877 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: 7877 <at> debbugs.gnu.org, jim <at> meyering.net
Subject: Re: bug#7877: sleep takes undocumented hex args
Date: Fri, 21 Jan 2011 21:43:35 +0000

On 21/01/11 19:28, Jim Meyering wrote:
> Paul Eggert wrote:
>> On 01/21/2011 01:24 AM, Jim Meyering wrote:
>>> My first reflex was to make sleep reject args like 0x... and inf.
>>
>> My reflex was just the opposite: why reject a notation
>> that might be useful?
> 
> I see that at least freebsd's /bin/sleep and the one from sunos 5.11
> work just like the one from coreutils (without my proposed change)
> in accepting e.g., 0x1 and inf.

freeBSD 8.1 treats 0x01 and inf as 0
sunos 5.10 rejects both

> 
> netbsd's accepts 0x1 but not inf.
> openbsd's accepts neither.

cheers,
Pádraig.

Message #55 received at 7877 <at> debbugs.gnu.org (full text, mbox):

From: jidanni <at> jidanni.org
To: 7877 <at> debbugs.gnu.org
Subject: sleep 5 -4
Date: Tue, 25 Jan 2011 07:26:56 +0800

$ sleep 5 -4
sleep: invalid option -- '4'
$ sleep -- 5 -4
sleep: invalid time interval `-4'

No fair prejudicing negative numbers.

At least document it.
'However, GNU `sleep' accepts arbitrary floating point numbers (using a
period before any fractional digits).' is what it says on Debian.

Message #58 received at 7877 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: jidanni <at> jidanni.org
Cc: 7877 <at> debbugs.gnu.org
Subject: Re: bug#7877: sleep 5 -4
Date: Tue, 25 Jan 2011 09:36:40 +0100

jidanni <at> jidanni.org wrote:
> $ sleep 5 -4
> sleep: invalid option -- '4'
> $ sleep -- 5 -4
> sleep: invalid time interval `-4'
>
> No fair prejudicing negative numbers.
>
> At least document it.
> 'However, GNU `sleep' accepts arbitrary floating point numbers (using a
> period before any fractional digits).' is what it says on Debian.

Hi Dan,

GNU sleep requires nonnegative numbers, so I've mentioned that
in the texinfo documentation.  I nearly made the s/arbitrary/nonnegative/
change to the sentence in both --help and coreutils.texi:

    Unlike most implementations that require NUMBER be an integer,
    here NUMBER may be an arbitrary floating point number.

But that seemed counterproductive, since we're making the contrast
between integer and FP.  Adding "nonnegative" there would detract.

Other implementations accept only a single argument,
so negative numbers would not make sense.


From 228b7b3c85b85a14b702aac1642b931798916809 Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering <at> redhat.com>
Date: Tue, 25 Jan 2011 09:22:37 +0100
Subject: [PATCH] doc: mention that each sleep argument must be nonnegative

* doc/coreutils.texi (sleep invocation): Document that arguments
must be nonnegative.  Reported by Dan Jacobson.
---
 doc/coreutils.texi |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index ebe379e..398e20c 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -15674,7 +15674,7 @@ sleep invocation
 @end example

 @cindex time units
-Each argument is a number followed by an optional unit; the default
+Each argument is a nonnegative number followed by an optional unit; the default
 is seconds.  The units are:

 @table @samp
--
1.7.3.5.38.gb312b

Message #61 received at 7877 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jim Meyering <jim <at> meyering.net>
Cc: 7877 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#7877: sleep 5 -4
Date: Tue, 25 Jan 2011 01:27:49 -0800

OK, so it's late, but I can't resist:

First, 'sleep' does accept one number that's negative
in an IEEE-754 sense, namely, "sleep -- -0.0".

Second, due to rounding error, 'sleep' does accept some
numbers that are negative in a mathematical sense, e.g.,
"sleep -- -1e1000" works.

Third, there's nothing intrinsically wrong with 'sleep'
accepting negative numbers.  All that POSIX
requires is that 'sleep' must sleep for at *least* the
amount of time specified.  So, if "sleep -- -1.0"
is treated like "sleep 0", then it's conforming to
that requirement of POSIX (obviously it doesn't
conform to the other requirement that the operand be
a nonnegative decimal integer; but it's a valid extension
that is consistent with POSIX).

(Have I written enough to tempt you to extend 'sleep'
to allow negative numbers?  :-)

Message #64 received at 7877 <at> debbugs.gnu.org (full text, mbox):

From: jidanni <at> jidanni.org
To: eggert <at> cs.ucla.edu
Cc: 7877 <at> debbugs.gnu.org, jim <at> meyering.net
Subject: Re: bug#7877: sleep 5 -4
Date: Tue, 25 Jan 2011 18:54:35 +0800

>>>>> "PE" == Paul Eggert <eggert <at> cs.ucla.edu> writes:
PE> (Have I written enough to tempt ... to extend 'sleep'
PE> to allow negative numbers?  :-)
Right you are young man.
We here at NerdLabs already use
$ sleep -- -100
to give us a few moments to go back and correct errors.
But due to National Security, that's all I can say, except that one
shouldn't make assumptions about what future generations might want to do...

Message #67 received at 7877 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 7877 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#7877: sleep 5 -4
Date: Tue, 25 Jan 2011 12:28:28 +0100

Paul Eggert wrote:
> OK, so it's late, but I can't resist:

You obviously need to, er... sleep.

> First, 'sleep' does accept one number that's negative
> in an IEEE-754 sense, namely, "sleep -- -0.0".
>
> Second, due to rounding error, 'sleep' does accept some
> numbers that are negative in a mathematical sense, e.g.,
> "sleep -- -1e1000" works.
>
> Third, there's nothing intrinsically wrong with 'sleep'
> accepting negative numbers.  All that POSIX
> requires is that 'sleep' must sleep for at *least* the
> amount of time specified.  So, if "sleep -- -1.0"
> is treated like "sleep 0", then it's conforming to
> that requirement of POSIX (obviously it doesn't
> conform to the other requirement that the operand be
> a nonnegative decimal integer; but it's a valid extension
> that is consistent with POSIX).

Maybe there is a use (albeit far-fetched) for negative numbers.
Let's say you want to sleep for 5 seconds less than a day.
Which would you prefer?
This:
    sleep -- 1d -5s
or this:
    sleep -- $((24*3600 - 5))s

> (Have I written enough to tempt you to extend 'sleep'
> to allow negative numbers?  :-)

I would accept the change.
Do you feel like writing it?

Message #70 received at 7877 <at> debbugs.gnu.org (full text, mbox):

From: James Cloos <cloos <at> jhcloos.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: 7877 <at> debbugs.gnu.org, Eric Blake <eblake <at> redhat.com>,
	bernhard.voelker <at> siemens-enterprise.com, jidanni <at> jidanni.org
Subject: Re: bug#7877: sleep takes undocumented hex args
Date: Thu, 27 Jan 2011 20:00:40 -0500

>>>>> "JM" == Jim Meyering <jim <at> meyering.net> writes:

JM> I see no significant utility in accepting hex floats.  Do you?
JM> If you're concerned about errors in conversion or the efficiency
JM> of the conversion process, then you probably don't want to use
JM> the sleep command in the first place.

the reason would be those cases where hex float literals are the default
output format for some given language.

I don't know that any exist now, but I also don't see any reason to
preclude them.

Hex floats are, generally speaking, a nice progression.

-JimC
-- 
James Cloos <cloos <at> jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Previous Next

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