bug-gnulib
[Top][All Lists]
Advanced

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

Re: parse-duration.c - TIME_MAX 2038 unpreparedness


From: Jonas 'Sortie' Termansen
Subject: Re: parse-duration.c - TIME_MAX 2038 unpreparedness
Date: Wed, 11 Jun 2014 22:38:46 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

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. :-)

Jonas



reply via email to

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