[Python-Dev] libffi embedded in CPython

[Maciej Fijalkowski]

On Wed, Mar 11, 2015 at 8:31 PM, Wes Turner <wes.turner at gmail.com> wrote:
>
> On Mar 11, 2015 12:55 PM, "Maciej Fijalkowski" <fijall at gmail.com> wrote:
>>
>> On Wed, Mar 11, 2015 at 7:50 PM, Antoine Pitrou <solipsis at pitrou.net>
>> wrote:
>> > On Wed, 11 Mar 2015 17:27:58 +0000
>> > Brett Cannon <brett at python.org> wrote:
>> >>
>> >> Did anyone ever step forward to do this? I'm a bit worried about the
>> >> long-term viability of ctypes if we don't have a maintainer or at least
>> >> someone making sure we are staying up-to-date with upstream libffi. The
>> >> ctypes module is a dangerous thing, so having a chunk of C code that
>> >> isn't
>> >> being properly maintained seems to me to make it even more dangerous.
>> >
>> > Depends what you call "dangerous". C code doesn't rot quicker than pure
>> > Python code :-) Also, libffi really offers a wrapper around platform
>> > ABIs, which rarely change.
>>
>> And yet, lesser known ABIs in libffi contain bugs (as we discovered
>> trying to work there with anything else than x86 really). Also there
>> *are* ABI differencies that change slowly over time (e.g. requiring
>> stack to be 16 byte aligned)
>
> Are there tests for this?
>

What do you mean? The usual failure mode is "will segfault every now
and again if the moon is in the right position" (e.g. the stack
alignment thing only happens if the underlaying function uses certain
SSE instructions that compilers emit these days in certain
circumstances)