Re: parse-duration.c - TIME_MAX 2038 unpreparedness

[Jim Meyering]

On Wed, Jun 11, 2014 at 1:38 PM, Jonas 'Sortie' Termansen
<address@hidden> wrote:
> Hi Bruce,
>
> On 06/11/2014 02:38 AM, Bruce Korb wrote:
>> OK, I promise to fix it within the next 24 years.
>
> It will be a while before any 2038 issues happen, yeah.  Though, some
> operating systems vendors today are making guarantees that their current
> installations will be able to last past that point.
>
>> In truth, since this is a _duration_, it really constrains the
>> result to be within 68 years.
>
> Durations longer than 68 years would indeed be unusual.  (Though can
> this code be abused to parse absolute dates?)  Either way, this is a
> silly artificial restriction: The code takes great care not to overflow
> beyond the limit, but the limit isn't always right.  Jim points out the
> TYPE_MAXIMUM () macro from lib/intprops.h, it looks reliable and ideal
> for this purpose.  (It also avoids the problem yours had where
> right-shifts on negative signed integers can be either arithmetic or
> logical.)
>
> The TIME_MAX macro is currently just used twice and both uses are in the
> scale_n_add function. It would probably be sufficient to just discard
> the macro and instead use this declaration in scale_n_add:
>
>   time_t time_max = TYPE_MAXIMUM (time_t);
>
> That should be clean, simple and reliable - and make everyone happy. :-)

I wrote the patch, and tested by running this:

  ./gnulib-tool --create-testdir --dir=/tmp/x --with-tests --test parse-duration

0001-parse-duration-eliminate-31-31-bit-time_t-limitation.txt
Description: Text document