On Fri, 7 Dec 2012, Philip Hazel wrote:

I think this patch happened because "#if HAVE_STDINT_H" gives an error if HAVE_STDINT_H is not defined, and the autotools do indeed #undef it when <stdint.h> does not exist.

Yes, this was due to me. I normally build with GCC's -Wundef, and while that only generates warnings rather than errors, these are easy to fix.

In fact, all the conditional code in PCRE uses tests for definition (#ifdef, #ifndef, or #if defined) rather than tests for a macro value.

That's standard Autoconf/GNU convention, and I would keep it that way.

The problem:

Somebody editing config.h.generic by hand, who doesn't have <stdint.h>
on there system, is quite likely to set

#define HAVE_STDINT_H 0

but of course that will not now work. This particular case can be bodged
by using  #if defined HAVE_STDINT_H && HAVE_STDINT_H

*winces*

but I would like a more general solution.  We could:

(a) Stop massaging config.h.generic, but that would still suggest
setting the value to 0.

People who aren't familiar with the Autoconf/GNU world would be a particular concern here.

(b) Massage the comment in config.h.generic to say use #undef rather
than setting to 0.

I think documenting this, and placing the burden on the user, is the right way to go. You could put a comment like "/* 1 or undefined */" on the same line as the #define/#undef.

(c) Modify all the tests in the code to test existence and value instead
of just existence. This might be a bit messy.

Akin to paving all the world's roadways with rubber so that automobiles don't need tires anymore :]

(d) Something else?

You could have a sanity check somewhere along the lines of

        #if defined(HAVE_STDINT_H) && (HAVE_STDINT_H - 0) != 1
        #  error "HAVE_STDINT_H must either be 1 or undefined"
        #endif

but I don't think going above and beyond option (b) is necessary.


--Daniel


--
Daniel Richard G. || [email protected] || Software Developer
Teragram Linguistic Technologies (a division of SAS)
http://www.teragram.com/


--
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev

Reply via email to