distutils: Unclear how CCompiler.has_function works for functions with parameters

[fweimer-rh]

As of 745c9d9, the C source fragment generator looks like this:

            for incl in includes:
                f.write("""#include "%s"\n""" % incl)
            f.write("""\
int main (int argc, char **argv) {
    %s();
    return 0;
}
""" % funcname)

Let's assume that the checked function actually exists and has one or more arguments. There are two cases to consider:

1. Include files are specified, and the function is declared in the include files.
2. No include files are specified, or the function is not declared.

In the first case, compilation fails because not enough arguments are specified in the function call. We never get to the linking stage.

In the second case, compilation still fails with strict C compilers (Clang 16, probably future GCC 14) because implicit function declarations are a C89 feature that was removed from C99 and future language standards. Implicit function declarations are well-known to send programmers on wild goose chases if they miss the compiler warning, so we really, really want to turn this into a compiler error. But autoconf-style checking like this is rather troublesome in this context.

This means that has_function really can't detect functions successfully (at least if they expect more than one argument).

Autoconf works around this by supplying a char foo(); declaration and calling that (still in a link-only test), but that does not allow the detection of alternative macro implementations. It is incompatible with the header file list that is allegedly supported by has_function: If you supply your own definition, you must not include any header files that potentially conflict with it.

(Found via the Fedora C99 porting project.)

[JelleZijlstra]

It looks like you are talking about distutils.ccompiler. The distutils package is deprecated and due to be removed, so I'm not sure we'll still be fixing bugs like this one.

[fweimer-rh]

Oy, I worried about that. What's the removal schedule for distutils? The Clang and GCC updates really need this fixed in some way. If distutils were gone, we could just tell affected packages to port to something else. If distutils is still around, there might be an expectation that we (as the Python or system compiler teams) provide a working has_function implementation.

[JelleZijlstra]

It's to be removed in Python 3.12. See PEP-632. There is a standalone version in https://github.com/pypa/distutils that I believe is still being developed.

[fweimer-rh]

Hmm, okay, I see that https://github.com/pypa/setuptools has pretty much the same code, so that and the out-of-tree distutils both have to be fixed. For Fedora's purposes, Python 3.12 will likely arrive just in time. But I expect that distributions not so lucky will be able to adapt the eventual setuptools fix to the bundled distutils version.

Is it possible to move this issue to setuptools, or should I file a new issue there?

[JelleZijlstra]

You'll have to open a new issue.

[sobolevn]

Closing, because we usually don't fix bugs in deprecated code.