Re: coreutils-8.14.116-1e18d on Linux/HPPA

[Bruno Haible]

Hi Pádraig,

> Hopefully the attached avoids this.

Your patch avoids the first 3 "fail=1" occurrences, but not the fourth one:

  + timeout 2.34e+5d sleep 0
  + test 124 = 0
  + fail=1

But is this really the desirable workaround? Do people want to have
"timeout 2.34e+5d sleep 0" really do different things on Linux/hppa
than on Linux/x86?

Why not add a workaround to the 'timeout' program, rather than to the tests?

Your guess about an overflow seems correct:

$ ./timeout 821760555 sleep 0 ; echo $?
t = 1325723090, duration_ceil = 821760555
0
$ ./timeout 821760557 sleep 0 ; echo $?
t = 1325723093, duration_ceil = 821760557
124

The limit appears to be INT_MAX.

The following patch fixes it for me.


2012-01-04  Bruno Haible  <address@hidden>

        timeout: Fix behaviour for end times beyond 2038 on Linux/hppa.
        * src/timeout.c (settimeout) [Linux/hppa]: Cap the duration, to avoid
        an overflow.

--- src/timeout.c.bak   2012-01-01 10:04:06.000000000 +0100
+++ src/timeout.c       2012-01-05 01:36:38.405115464 +0100
@@ -111,6 +111,13 @@
    deprecated by POSIX.  Instead we fallback to single second
    resolution provided by alarm().  */
 
+#if defined __linux__ && defined __hppa__
+  /* Work around an overflow that happens when the end date is beyond 2038.  
*/
+  time_t t = time (NULL);
+  if (t >= 0 && t <= INT_MAX && duration > (double) (INT_MAX - t))
+    duration = (double) (INT_MAX - t);
+#endif
+
 #if HAVE_TIMER_SETTIME
   struct timespec ts = dtotimespec (duration);
   struct itimerspec its = { {0, 0}, ts };