[Python-Dev] libffi inclusion in python (original) (raw)

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.

Thomas

More information about the Python-Dev mailing list