[Python-Dev] libffi embedded in CPython

[Maciej Fijalkowski]

On Thu, Dec 18, 2014 at 10:36 PM, Jim J. Jewett <jimjjewett at gmail.com> wrote:
>
>
> On Thu, Dec 18, 2014, at 14:13, Maciej Fijalkowski wrote:
>> ... http://bugs.python.org/issue23085 ...
>> is there any reason any more for libffi being included in CPython?
>
> [And why a fork, instead of just treating it as an external dependency]
>
> Benjamin Peterson responded:
>
>> It has some sort of Windows related patches. No one seems to know
>> whether they're still needed for newer libffi. Unfortunately, ctypes
>> doesn't currently have a maintainer.
>
> Are any of the following false?
>
> (1)  Ideally, we would treat it as an external dependency.
>
> (2)  At one point, it was intentionally forked to get in needed
> patches, including at least some for 64 bit windows with MSVC.
>
> (3)  Upstream libffi maintenance has picked back up.
>
> (4)  Alas, that means the switch merge would not be trivial.
>
> (5)  In theory, we could now switch to the external version.
> [In particular, does libffi have a release policy such that we
> could assume the newest released version is "safe", so long as
> our integration doesn't break?]
>
> (6)  By its very nature, libffi changes are risky and undertested.
> At the moment, that is also true of its primary user, ctypes.
>
> (7)  So a switch is OK in theory, but someone has to do the
> non-trivial testing and merging, and agree to support both libffi
> and and ctypes in the future.  Otherwise, stable wins.
>
> (8)  The need for future support makes this a bad candidate for
> "patches wanted"/"bug bounty"/GSoC.
>
> -jJ

I would like to add that "not doing anything" is not a good strategy
either, because you accumulate bugs that get fixed upstream (I'm
pretty sure all the problems from cpython got fixed in upstream
libffi, but not all libffi fixes made it to cpython).