coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jim Meyering
Subject: Re: coreutils-8.14.116-1e18d on Linux/HPPA
Date: Tue, 10 Jan 2012 19:18:35 +0100

Pádraig Brady wrote:
> On 01/05/2012 04:05 AM, Bruno Haible wrote:
>> 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.
>
> That's safer thanks, but...
>
> It really goes against the grain for me,
> to add stuff like this to the code unless
> absolutely necessary.
>
> In this case I don't think it's a practical issue because:
>
> 1. The failure mode is only of practical concern close to 2038
> 2. It adds artificial limits which will incur maintenance overhead
> between now and 2038
> 3. The failure mode is immediate and obvious to users
> 4. It's a dead end platform, last sold in 2008 and not supported after 2013
> 5. It's probably a trivial fix in the kernel, which has 26 years to get to 
> users

[found this 5-day-old buffer, sending anyway]
Sounds fair.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]