Good way of finding out what C functions we have?

I just did a bunch of research into trying to find out if using strdup() in a patch was reasonable. I finally grepped enough to find strdup in pyconfig.h and configure.in . But that leads to a Brett Newbie Question. Does there happen to be a better way to find out what functions we check for beyond grepping configure.in? The entire reason I bothered to do so much research is I thought we were only supposed to assume ANSI C with POSIX (which, from what I can tell, strdup() is not). But with more Googling and grepping I discovered the meaning of AC_REPLACE_FUNCS() which strdup was being called in configure.in . I would never have known strdup was available to me for code had I not randomly come across this patch and done all of this research. Because of this I would like to list in the Python development guide I am writing up all of the places one can check for info; what configure.in checks for or handles and pyport.h come to mind. It would be nice to have a place that lists all the places one can check for C functionality that are not in the Python/C API directly. If people have other places in the code that one should check please let me know so I can make sure it makes it into the doc and prevents me from having to come up with another Brett Newbie Question. =) -Brett

"Brett C." <bac@OCF.Berkeley.EDU> writes:
Actually, strdup is in POSIX: http://www.opengroup.org/onlinepubs/007904975/functions/strdup.html If we still check for it, it is because it might not have been available on some system, at some point in time.
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. Regards, Martin

Martin v. Löwis wrote:
Shows how much I know; I found that last night but since it didn't say POSIX anywhere I thought it was part of another standard. I guess the "Issue 5" mention means that BASE is POSIX? Or is IEEE 1003.1 basically POSIX?
If we still check for it, it is because it might not have been available on some system, at some point in time.
We don't only check for it, but we have a replacement implementation (the comment for Python/strdup.c seems to suggest it is needed by the parser).
What does happen if a HAVE_foo is actually required? Does the build fail or will configure halt and say that the build will fail if you proceed? And if no one objects I will mention that looking in pyconfig.h.in is a good place to look to see what C functions that are non-POSIX and non-ANSI C we check for and pyport.h has helpful stuff as well. -Brett

>> 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

Skip Montanaro wrote:
As in Python will not be at all functional without the functionality being required.
Right. I was wondering if there are any checks in configure.in that if something was not available that Python itself would not compile *at all*. I would suspect not since that is what the ANSI C/POSIX coding requirement is supposed to handle, right? -Brett

"Brett C." <bac@OCF.Berkeley.EDU> writes:
In the past, the various standards different slightly. Today, IEEE 1003.1 is the same as ISO/IEC 9945:2003 (parts 1..4), is the same as Single Unix version 3, is the same as XPG/5. It contains the OpenGroup's XBD, XSH, XCU, and XRAT documents. The UNIX product standard (which apparently hasn't been revised since '98) also covers XCURSES, XTI, and a few others; UNIX98 workstation also supports X11 and CDE.
configure only checks for the feature. If the feature is absent, yet we use the feature without an #ifdef, the build just fails; that would be a bug. Regards, Martin

"Brett C." <bac@OCF.Berkeley.EDU> writes:
Actually, strdup is in POSIX: http://www.opengroup.org/onlinepubs/007904975/functions/strdup.html If we still check for it, it is because it might not have been available on some system, at some point in time.
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. Regards, Martin

Martin v. Löwis wrote:
Shows how much I know; I found that last night but since it didn't say POSIX anywhere I thought it was part of another standard. I guess the "Issue 5" mention means that BASE is POSIX? Or is IEEE 1003.1 basically POSIX?
If we still check for it, it is because it might not have been available on some system, at some point in time.
We don't only check for it, but we have a replacement implementation (the comment for Python/strdup.c seems to suggest it is needed by the parser).
What does happen if a HAVE_foo is actually required? Does the build fail or will configure halt and say that the build will fail if you proceed? And if no one objects I will mention that looking in pyconfig.h.in is a good place to look to see what C functions that are non-POSIX and non-ANSI C we check for and pyport.h has helpful stuff as well. -Brett

>> 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

Skip Montanaro wrote:
As in Python will not be at all functional without the functionality being required.
Right. I was wondering if there are any checks in configure.in that if something was not available that Python itself would not compile *at all*. I would suspect not since that is what the ANSI C/POSIX coding requirement is supposed to handle, right? -Brett

"Brett C." <bac@OCF.Berkeley.EDU> writes:
In the past, the various standards different slightly. Today, IEEE 1003.1 is the same as ISO/IEC 9945:2003 (parts 1..4), is the same as Single Unix version 3, is the same as XPG/5. It contains the OpenGroup's XBD, XSH, XCU, and XRAT documents. The UNIX product standard (which apparently hasn't been revised since '98) also covers XCURSES, XTI, and a few others; UNIX98 workstation also supports X11 and CDE.
configure only checks for the feature. If the feature is absent, yet we use the feature without an #ifdef, the build just fails; that would be a bug. Regards, Martin
participants (3)
-
Brett C.
-
martin@v.loewis.de
-
Skip Montanaro