[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: dfa.c order of include problem

From: Paul Eggert
Subject: Re: dfa.c order of include problem
Date: Fri, 01 Feb 2013 00:17:42 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]