Re: parse-duration.c - TIME_MAX conflict

[Jonas 'Sortie' Termansen]

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 misunderstand my short remark in my original email. I'm not
associated with glibc or GNU (beside a few odd contributions here and
there) and as far as I know they don't have or plan to have a TIME_MAX
constant. I wrote my own custom operating system 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-duration.c
file in the fist place.

What I meant is that such a constant would be fairly useful (in code
such as this, for instance) and other libcs/standards could potentially
add one as well (likely not), I recognize its potential to collide with
some existing code.

Regardless that was just a side remark and my issue here wasn't the use
of TIME_MAX, but rather the hard-coded limit. You can continue to use
the identifier TIME_MAX if you wish, it's a bug if any of my standard
headers declares such a constant when adhering to POSIX.

The patch looks good to me as well. :-)

Jonas