On Thu, Apr 18, 2013 at 9:22 PM, Thomas Heller <thel...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
