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
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
On 06/15/2014 06:53 PM, Bruce Korb wrote:
> Actually, it occurs to me that the result still uses TIME_MAX and, if
> not guarded,
> still conflicts with glibc's claim to a new name. I still think that
> "implementations"
> need an unambiguously distinct name space. *_MAX is too greedy.
Ah, don't
On 06/14/14 14:37, Bruce Korb wrote:
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!
Actually, it occurs to me that the result stil
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 Bruce,
* Bruce Korb wrote on Sat, Dec 27, 2008 at 11:36:56PM CET:
> > So, I've now had another gander now, too.
> > A small doc tweak and coding aesthetics issue:
>
> This should probably be applied. I don't have "push" privs on the
> repository. What should I do? Thanks. - Bruce
I'm not a
Bruce Korb wrote:
> So, I've now had another gander now, too.
> A small doc tweak and coding aesthetics issue:
This should probably be applied. I don't have "push" privs on the
repository. What should I do? Thanks. - Bruce
> $ diff -up gnulib/ChangeLog gnulib-clone/ChangeLog
> --- gnulib/Chang
12 matches
Mail list logo
