On 05/04/2025 12:03, Pádraig Brady wrote:
> On 05/04/2025 09:03, Paul Eggert wrote:
>> On 2025-04-04 12:27, Pádraig Brady wrote:
>>> +  /* Clamp underflow to 1ns, as 0 disables the timeout.  */
>>> +  if (duration == 0 && errno == ERANGE)
>>> +    duration = 1e-9;
>>
>> That isn't exactly right as the 1e-9 double-rounds to 2e-9 when we
>> compute the struct timespec. Also, even with the patch the code
>> mishandles 16777216.000000001 (2**24 + 10**-9) by treating it as if it
>> were just 16777216. These are tiny bugs, I know, but I took up the
>> challenge of doing this things more correctly by installing the attached.
> 
> This is the first time coreutils is linking with libm.
> So practically that does add measurable overhead:
> 
>     $ time seq 10000 | xargs -n1 src/timeout-old >/dev/null
>     real    0m7.139s
> 
>     $ time seq 10000 | xargs -n1 src/timeout >/dev/null
>     real    0m8.161s
> 
> So on my 2.6GHz i7-5600U we're adding 102,200 ns to the startup time,
> to address theoretical single nanosecond issues.
> Given the code is also more complex, I'm thinking using libm is not worth it?
> 
> BTW I'll apply the attached cleanups if we keep the libm dependency.

I'm going to apply the attached later to remove the libm dependency.
It's just too much of a dependency for minimal functionality.
All existing tests are maintained, and still pass.

cheers,
Pádraig