[Python-Dev] Cython, Ctypes and the stdlib

[Stefan Behnel]

Dan Stromberg, 01.09.2011 19:56:
> On Tue, Aug 30, 2011 at 10:05 AM, Guido van Rossum wrote:
>>   The problem lies with the PyPy backend -- there it generates ctypes
>> code, which means that the signature you declare to Cython/Pyrex must
>> match the *linker* level API, not the C compiler level API. Thus, if
>> in a system header a certain function is really a macro that invokes
>> another function with a permuted or augmented argument list, you'd
>> have to know what that macro does. I also don't see how this would
>> work for #defined constants: where does Cython/Pyrex get their value?
>> ctypes doesn't have their values.
>>
>> So, for PyPy, a solution based on Cython/Pyrex has many of the same
>> downsides as one based on ctypes where it comes to complying with an
>> API defined by a .h file.
>
> It's certainly a harder problem.
>
> For most simple constants, Cython/Pyrex might be able to generate a series
> of tiny C programs with which to find CPP symbol values:
>
> #include "file1.h"
> ...
> #include "filen.h"
>
> main()
> {
> printf("%d", POSSIBLE_CPP_SYMBOL1);
> }
>
> ...and again with %f, %s, etc.The typing is quite a mess

The user will commonly declare #defined values as typed external variables 
and callable macros as functions in .pxd files. These manually typed 
"macro" functions allow users to tell Cython what it should know about how 
the macros will be used. And that would allow it to generate C/C++ glue 
code for them that uses the declared types as a real function signature and 
calls the macro underneath.


> and code fragments would probably be impractical.

Not necessarily at the C level but certainly for a ctypes backend, yes.


> But hopefully clang has something that'd make this easier.

For figuring these things out, maybe. Not so much for solving the problems 
they introduce.

Stefan