On Wed, Mar 11, 2015 at 8:31 PM, Wes Turner <wes.tur...@gmail.com> wrote: > > On Mar 11, 2015 12:55 PM, "Maciej Fijalkowski" <fij...@gmail.com> wrote: >> >> On Wed, Mar 11, 2015 at 7:50 PM, Antoine Pitrou <solip...@pitrou.net> >> wrote: >> > On Wed, 11 Mar 2015 17:27:58 +0000 >> > Brett Cannon <br...@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) _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
