[Top][All Lists]

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

Re: parse-duration.c - TIME_MAX 2038 unpreparedness

From: Bruce Korb
Subject: Re: parse-duration.c - TIME_MAX 2038 unpreparedness
Date: Tue, 10 Jun 2014 17:38:15 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130922 Icedove/17.0.9

On 06/01/14 10:04, Jonas 'Sortie' Termansen wrote:

I noticed that lib/parse-duration.c does:


This is naturally entirely unacceptable as the 2038 bug ((time_t)
INT32_MAX) is coming up soon

OK, I promise to fix it within the next 24 years.

In truth, since this is a _duration_, it really constrains the
result to be within 68 years.  I did actually think about it
for a few moments and decided a rigorous solution didn't warrant
the effort.

It would probably be best to not use a define named TIME_MAX, as that
name would be ideal if a standard header wanted to expose the domain of
time_t for use in cases like this (indeed, this came up because I am
adding a TIME_MAX constant to my libc).

I also Googled for a POSIX "It's mine and you can't have it" statement
for the value name and got no results.  I do kind-of like the DEC
regime of prefixing values with "SYS$", but that is another world.
Since that value is used internally, I'll just prefix it with:

  #undef TIME_MAX

and document the "constraint" that time differences beyond 68 years
are not supported.

Or maybe:

#ifdef TIME_MAX
#define TIME_LIMIT (((time_t)~0) >> 1)

But I really think 68 years will cover the need. :)

Cheers - Bruce

reply via email to

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