Re: dfa.c order of include problem

[Eric Blake]

On 01/31/2013 11:39 AM, address@hidden wrote:
> Hi.
> 
>> Rather, doesn't that mean that <regex.h> should #include <limits.h>
>> prior to redefining RE_DUP_MAX, to be sure that it overrides any limits
>> that would otherwise be present in the system headers?
> 
> That would be nice, but hell will likely freeze over before glibc
> updates it for us.

Glibc <regex.h> does not have the problem, and gnulib <regex.h> is
perfectly capable of overriding system headers in order to guarantee
sane semantics (we've done it in multiple situations).

> 
>> Having dfa.h be included first is a feature - it proves that our header
>> is self-contained.  I'd rather fix the real problem in <regex.h>.
> 
> The problem is dfa.c that includes limits.h after regex.h is included.
> If you leave it as is you are then relying on all systems to have header
> files that guard against multiple includes.

The C standard requires that all standard C headers except <assert.h> be
idempotent; and that reincluding them a second time has no effect.

> On GLIBC systems you can
> make that assumption.  I'm not willing to do so for the broader range
> of systems out there.

Any system where this is not true is in violation of the C standard; and
even if we were to find such a system (to my knowledge, none exist), I
still think gnulib would be able to work around a broken <limits.h>.
There's no point in making life insane for ourselves by catering to
broken systems that don't exist.

> 
> I personally prefer to include all system headers first, which allows me,
> in the files that I control, to then compensate for system idiosyncracies.
> 
> To each his own.
> 
> Thanks,
> 
> Arnold
> 
> 

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature