Re: parse-duration.c - TIME_MAX conflict

On 06/17/14 09:06, Jonas 'Sortie' Termansen wrote: It actually turns out that POSIX has reserved the _MIN and _MAX suffixes for as stated in POSIX 2008 `2.2.2 The Name Space'. It has a nice table with all the POSIX namespace rules that you can view online: http://pubs.opengroup.org/onlinepubs/9

Re: parse-duration.c - TIME_MAX conflict

On 06/15/2014 06:53 PM, Bruce Korb wrote: > I still think that "implementations" need an unambiguously distinct > name space. *_MAX is too greedy. It actually turns out that POSIX has reserved the _MIN and _MAX suffixes for as stated in POSIX 2008 `2.2.2 The Name Space'. It has a nice table with

Re: parse-duration.c - TIME_MAX conflict

with a custom libc and ported software using gnulib to it. My addition of a TIME_MAX constant (as well as limit, print and scan macros for all sys/types.h typedefs) is a non-standard extension to my libc and it is properly hidden behind feature macros - and shouldn't even conflict with the parse-d

Re: parse-duration.c - TIME_MAX conflict

angeLog @@ -1,3 +1,13 @@ +2014-06-11 Bruce Korb + Jim Meyering + + parse-duration: eliminate 68 year duration limit + * lib/parse-duration.c: Include "intprops.h". + (TIME_MAX): rename to MAX_DURATION and define to + TYPE_MAXIMUM(time_t). + * modules/parse-duration (Depends-on): Add intp

Re: parse-duration.c - TIME_MAX 2038 unpreparedness

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!

Re: parse-duration.c - TIME_MAX 2038 unpreparedness

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

Re: parse-duration.c - TIME_MAX 2038 unpreparedness

sted by running this: ./gnulib-tool --create-testdir --dir=/tmp/x --with-tests --test parse-duration From afa7c4a28feaac74b7d64b22c61a73377a9c0f2a Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Wed, 11 Jun 2014 15:43:37 -0700 Subject: [PATCH] parse-duration: eliminate 31/31-bit time_t limitation * lib/parse-duration.c: Incl

Re: parse-duration.c - TIME_MAX 2038 unpreparedness

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

Re: parse-duration.c - TIME_MAX 2038 unpreparedness

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

Re: parse-duration.c - TIME_MAX 2038 unpreparedness

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,

parse-duration.c - TIME_MAX 2038 unpreparedness

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

Re: parse-duration.c

21 08:47:26.0 -0800 > > +++ gnulib-clone/ChangeLog 2008-12-21 11:50:18.0 -0800 > > @@ -1,3 +1,8 @@ > > +2008-11-17 Bruce Korb > > + > > + * lib/parse-duration.h: non-iso form accepts years, months weeks, > > too > > + * lib/parse-duration.c: use a switch instead of cascading if's. > > +

Re: parse-duration.c

-clone/ChangeLog > --- gnulib/ChangeLog2008-12-21 08:47:26.0 -0800 > +++ gnulib-clone/ChangeLog 2008-12-21 11:50:18.0 -0800 > @@ -1,3 +1,8 @@ > +2008-11-17 Bruce Korb > + > + * lib/parse-duration.h: non-iso form accepts years, months weeks, too > +

parse-duration.c

11-17 Bruce Korb + + * lib/parse-duration.h: non-iso form accepts years, months weeks, too + * lib/parse-duration.c: use a switch instead of cascading if's. + 2008-12-21 Bruno Haible Work around a btowc() bug on IRIX 6.5. $ diff -up gnulib/lib/parse-duration.c gnulib

Re: Add missing include to parse-duration.c.

ies. Thanks to both of you, pushed like this. Cheers, Ralf add missing include to parse-duration.c * lib/parse-duration.c: #include "xalloc.h", for xstrdup. * modules/parse-duration (Depends-on): Add xalloc. diff --git a/lib/parse-duration.c b/lib/parse-duration.c index 64

Re: Add missing include to parse-duration.c.

Hi Ralf, Obvious enough you needn't have waited for me. :) "Yes, please." Cheers - Bruce On Mon, Dec 8, 2008 at 10:18 PM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > Hello Bruce, > > ok to commit? Seems pretty obvious. > > Thanks, > Ralf > &g

Re: Add missing include to parse-duration.c.

Ralf Wildenhues wrote: > * lib/parse-duration.c: #include "xalloc.h", for xstrdup. This also requires an update of the module dependencies. Bruno

Add missing include to parse-duration.c.

Hello Bruce, ok to commit? Seems pretty obvious. Thanks, Ralf Add missing include to parse-duration.c. * lib/parse-duration.c: #include "xalloc.h", for xstrdup. diff --git a/lib/parse-duration.c b/lib/parse-duration.c index 6487ba0..4c28349 100644 --- a/lib/parse-durati