On 01/31/2013 11:48 PM, Aharon Robbins wrote: >>>> Glibc <regex.h> does not have the problem, >>> > > How is that so? The undef of RE_DUP_MAX and redefine is there. >>> > > If limits.h is included after regex.h, then the value from limits.h >>> > > is applied. >> > >> > But in Glibc the two definitions are equivalent (identical preprocessor >> > token lists), so it's valid C and there's no problem. > You've missed the point. Using the glibc regex.h on a non-GLIBC system > where limits.h is included after regex.h does not solve anything.
I think Eric Blake was talking about glibc regex.h in the context of glibc, whereas you're talking about it in a different context, where glibc regex.h is combined with some non glibc standard headers. Yes, in that case one can have problems. But surely it's better to fix regex.h so that it conforms to POSIX in this respect, than to fix all of regex.h's users to work around the bug. Gnulib regex.h does that: it is designed to be portable to non-glibc environments, and it fixes the problem.
