Pádraig Brady wrote: > > No, time_t is typedefed to 'long int' (32-bit but signed) on this platform. > > Right, so if time_t is changed to 64 bit there in future, > the test would be too restrictive?
time_t cannot be changed to 64-bit without breaking binary compatibility or adding lots of new versioned symbols to libc. I doubt Ulrich will do this for a 32-bit platform. The policy has been to do this change only for 64-bit platforms. But if you want to be sure, feel free to add a condition: if (sizeof (time_t) == sizeof (int) && ....) > So I'm leaning towards the deeper probing and avoidance, > done in the shell script. It does not help the robustness of shell scripts of users out there if you leave the bug in the 'timeout' program and just paper over the test failures. Find attached a revised patch. Bruno
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-05 05:01:01.000000000 +0100 +++ src/timeout.c 2012-01-05 05:02:23.000000000 +0100 @@ -111,6 +111,16 @@ 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. */ + if (sizeof (time_t) == sizeof (int)) + { + 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 };
