Re: xnanosleep range with 64 bit time_t

[Paul Eggert]

Frank v Waveren <address@hidden> writes:

> I haven't checked how other operating systems handle this (do any
> others even have 64 bit time_t's?)

Yes, pretty much every operating system with 64-bit long has 64-bit
time_t, which means most OSes these days (at least on some platform).
So we can't install that patch as-is: it would break things on too
many platforms.

> lib/xnanosleep.c currently assumes nanosleep works with any value that
> can be fit into the struct timespec. For gnu+linux on a 
> platform with 64 bit longs, this isn't true (it currently doesn't even
> return and error but just silently integer-overflows, but I've
> submitted a patch to make it error).

That doesn't sound right.  Why not just fix nanosleep so that it works
instead?  It shouldn't be that hard.  There shouldn't be an arbitrary
upper bound to the length of the sleep.

Also, until the kernel bug gets fixed, what's the harm of leaving
coreutils alone?  The bug occurs only for sleeps longer than about 68
years, so it's not like this is a burning issue.