[Python-Dev] libffi inclusion in python

Maciej Fijalkowski fijall at gmail.com
Thu Apr 18 21:24:58 CEST 2013


On Thu, Apr 18, 2013 at 9:22 PM, Thomas Heller <theller at ctypes.org> wrote:
>>>> 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

Cool.

Note that I don't ask "why the hell was it included", I assume there
was the right choice at a time, I ask "can we remove it now?" which
seems to be mostly yes.

Cheers,
fijal


More information about the Python-Dev mailing list