GNU bug report logs - #9101
timeout should use setitimer if available

Previous Next

Full log

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 9101 <at> debbugs.gnu.org
Subject: Re: bug#9101: timeout should use setitimer if available
Date: Mon, 18 Jul 2011 16:05:44 -0700

On 07/18/11 15:17, Pádraig Brady wrote:
> I noticed that there was some info lost
> in the double -> 64bit conversion:
> 
> $ strace -e setitimer src/timeout 9223372036852775425 sleep 0
> setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={9223372036852775936, 0}}, NULL) = 0

The info is lost in converting string to double.
IEEE-754 double can represent integers exactly up through
2**52; then it starts losing information.  We could
work around this on x86 by going to long double, but...

> Not a practical issue for `timeout` at least.

Exactly.

>>    +      if (tv.tv_sec != LONG_MAX)
>> > 
>> > This LONG_MAX should be TYPE_MAXIMUM (time_t).
> Could it ever be 'long', and that being different to time_t?

Not on any host I know of.  Historically tv_sec has always
been of type time_t, and POSIX requires it; I don't expect
this to change.

> We don't need the extra resolution

This is true in a practical sense, but it'd be nice to do it
"right", if only for the future machines that can really
do sub-microsecond timing accurately.  Obviously this is low
priority though.

Previous Next

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