On 06/01/14 10:04, Jonas 'Sortie' Termansen wrote:
Hi,
I noticed that lib/parse-duration.c does:
#define TIME_MAX 0x7FFFFFFF
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_MAX
#else
#define TIME_LIMIT (((time_t)~0) >> 1)
#endif
But I really think 68 years will cover the need. :)
Cheers - Bruce
