On 01/31/2013 11:39 AM, [email protected] 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
