[Python-Dev] Good way of finding out what C functions we have? (original) (raw)

Skip Montanaro skip at pobox.com
Tue Sep 30 09:12:09 EDT 2003


>> I would look in pyconfig.h.in as the first thing. There is a pitfall,
>> though: presence of some HAVE_foo in pyconfig.h does not mean that
>> Python gracefully deals with the absence of foo. When converting
>> configure to autoconf 2.5x, I checked all macros to determine whether
>> they were still in use, but some may have become unused/not processed
>> correctly since. That would be a bug, of course.

Brett> What does happen if a HAVE_foo is actually required?  Does the
Brett> build fail or will configure halt and say that the build will
Brett> fail if you proceed?

It's not exactly clear what you mean by "required". All the HAVE_foo macros are supposed to indicate the presence (when defined) or absence (when not defined) of a particular "feature" which is not felt by one or more of the authors to be universally available. As far as I know, a HAVE_foo macro should never be required to be defined, though I suppose if we had an infinite amount of time on our hands be might code a configure test for HAVE_WRITE. HAVE_* macros should only be used in a conditional way like

#ifdef HAVE_FOO
   /* assume foo is available */
else
   /* assume foo is missing and code around its absence */
endif

or as in the case of fsync() in posixmodule.c

#ifdef HAVE_FSYNC
   /* define wrapper for fsync()
endif

The lack of a HAVE_foo macro definition might make an entire module unavailable. More often it causes a single module function to not be defined or for a messier or less efficient implementation to be used.

A rather extreme case was strptime(). It's always been known to not be available everywhere, and in cases where it was available it didn't always present the same semantics to the Python programmer. You can to the rescue and removed the need for that macro altogether (I think it's too ill-defined for the interpreter itself to rely on a consistent definition).

Skip



More information about the Python-Dev mailing list