bug#9101: timeout should use setitimer if available

[Paul Eggert]

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.