[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
parse-duration.c - TIME_MAX 2038 unpreparedness
From: |
Jonas 'Sortie' Termansen |
Subject: |
parse-duration.c - TIME_MAX 2038 unpreparedness |
Date: |
Sun, 01 Jun 2014 19:04:15 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 |
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 and most operating systems are 64-bit
time_t capable by now. This should be rewritten as something involving
sizeof(time_t) in a safe and portable manner.
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).
Jonas 'Sortie' Termansen
- parse-duration.c - TIME_MAX 2038 unpreparedness,
Jonas 'Sortie' Termansen <=
- Re: parse-duration.c - TIME_MAX 2038 unpreparedness, Bruce Korb, 2014/06/10
- Re: parse-duration.c - TIME_MAX 2038 unpreparedness, Jim Meyering, 2014/06/10
- Re: parse-duration.c - TIME_MAX 2038 unpreparedness, Jonas 'Sortie' Termansen, 2014/06/11
- Re: parse-duration.c - TIME_MAX 2038 unpreparedness, Jim Meyering, 2014/06/11
- Re: parse-duration.c - TIME_MAX 2038 unpreparedness, Bruce Korb, 2014/06/14
- Re: parse-duration.c - TIME_MAX conflict, Bruce Korb, 2014/06/15
- Re: parse-duration.c - TIME_MAX conflict, Jonas 'Sortie' Termansen, 2014/06/15
- Re: parse-duration.c - TIME_MAX conflict, Jonas 'Sortie' Termansen, 2014/06/17
- Re: parse-duration.c - TIME_MAX conflict, Bruce Korb, 2014/06/17