Re: dfa.c order of include problem

[Paul Eggert]

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.