[Python-Dev] libffi inclusion in python

Thomas Heller theller at ctypes.org
Thu Apr 18 21:22:10 CEST 2013

>>> libffi has bugs sometimes (like this
>>> http://bugs.python.org/issue17580). Now this is a thing that upstream
>>> fixes really quickly, but tracking down issues on bugs.python.org is
>>> annoying (they never get commited as quickly as the upstream). is
>>> there a good reason why cpython has it's own copy of libffi? I
>>> understand historical reasons, but PyPy gets along relying on the
>>> system library, so maybe we can kill the inclusion.
>> IIRC, it had (has?) some custom windows patches, which no one knows
>> whether they're relevant or not.

The only windows patch that is most certainly not in upstream is the
ability to check and correct the stack pointer after a windows function
call depending on the calling convention (stdcall or cdecl).

Since this is windows 32-bit only (on windows 64-bit these calling
conventions are aliases for the same thing), it would probably be good
to remove the distinction between them for function calls.

> Upstream seems to be incredibly responsive. Why not merge them there?

At the time when ctypes was implemented, this was different.  They
didn't even do libffi releases, IIRC.


More information about the Python-Dev mailing list