Re: xnanosleep range with 64 bit time_t

[Paul Eggert]

Frank v Waveren <address@hidden> writes:

> Thomas Gleixner has submitted a replacing patch that instead just
> limits the timespec passed to the maximum, so that would make this
> patch unnecessary for linux (at least for those with new kernels).

Sorry, no, that's worse.

With the current Linux behavior, I can detect the bug and work around
it at 'configure' time using AC_RUN_IFELSE.  The same is true for a
change to the kernel that would return EOVERFLOW for long sleeps; this
behavior is worse, in my opinion, since it will cause more work in the
application to work around, but the bug is still easily detectable at
configure-time.

But with Gleixner's proposed fix, I'd have to run a test program that
will take 70 years to run, if I want to detect the bug in the
resulting kernel.  (Most people wouldn't like it if './configure' took
70 years to execute.  I know 'configure' is slow, but reeeallly!  :-)


How about if you just fix nanosleep so that it works in general?
Surely nanosleep can just have a little loop like this:

     unsigned int eons = t.tv_sec >> 31;
     for (i = 0; i < eons; i++)
       sleep for 2**31 seconds;
     t.tv_sec &= 0x7FFFFFFF;

and then fall through to the existing behavior.  Am I missing something?
It sounds pretty easy.

If you can't fix the kernel bug, my advice is to leave the behavior
alone.  Please don't make things worse by introducing a new bug that
is harder for applications to work around than the existing bug.