On Wed, Mar 11, 2015 at 8:31 PM, Wes Turner email@example.com wrote:
On Mar 11, 2015 12:55 PM, "Maciej Fijalkowski" firstname.lastname@example.org wrote:
On Wed, Mar 11, 2015 at 7:50 PM, Antoine Pitrou email@example.com wrote:
On Wed, 11 Mar 2015 17:27:58 +0000 Brett Cannon firstname.lastname@example.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)