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 <[email protected]> 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 };
