Frank v Waveren <[EMAIL PROTECTED]> 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. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
