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
