On 06/11/14 15:46, Jim Meyering wrote:
I wrote the patch, and tested by running this:
./gnulib-tool --create-testdir --dir=/tmp/x --with-tests --test
parse-duration
Excellent. Please push it, thank you!
On 06/10/14 17:49, Jim Meyering wrote:
Why impose such a limit?
I'd go with TYPE_MAXIMUM (time_t).
a) because I do not read BASH headers (or any other headers) for fun.
Unless I get bumped somehow, I don't know about such things, and
b) like I said, if anybody on the planet really needs a t
On Wed, Jun 11, 2014 at 1:38 PM, Jonas 'Sortie' Termansen
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 gua
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
On Tue, Jun 10, 2014 at 5:38 PM, Bruce Korb wrote:
> Or maybe:
>
> #ifdef TIME_MAX
> #define TIME_LIMIT TIME_MAX
> #else
> #define TIME_LIMIT (((time_t)~0) >> 1)
> #endif
Why impose such a limit?
I'd go with TYPE_MAXIMUM (time_t).
On 06/01/14 10:04, Jonas 'Sortie' Termansen wrote:
Hi,
I noticed that lib/parse-duration.c does:
#define TIME_MAX 0x7FFF
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
Hi,
I noticed that lib/parse-duration.c does:
#define TIME_MAX 0x7FFF
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
