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.
