[Python-Dev] Good way of finding out what C functions we have?
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