On 01/05/2012 12:39 AM, Bruno Haible wrote: > 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
Oops right. > 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? No. But as long as the kernel gets fixed some reasonable time before 2038, we're OK. I'll report the bug tomorrow. > Why not add a workaround to the 'timeout' program, rather than to the tests? Because I'd rather have messy tests than messy code. > 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. Oh, so time_t is 64 bit there? > The following patch fixes it for me. > +#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 Not too onerous I suppose. I'll sleep on it :) cheers, Pádraig.
