On Thu, Apr 18, 2013 at 2:47 PM, Benjamin Peterson <benjamin at python.org> wrote: > 2013/4/18 Maciej Fijalkowski <fijall at gmail.com>: >> Hi >> >> 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. > > I personally would love to see all libraries that we have copies of in > the repo killed. Upstream seems to be incredibly responsive. Why not merge them there? Is it just "we can't patch distutils" crap? If we *really* need to provide libraries for systems that don't have them, how about simply having a separate download for those systems instead of using it on systems that *do* have them and in fact *do* have them in a better version. Note that the recent patches (one for 32bit, one for ARM) are easily security holes. I'm not 100% sure if segfault caused by stack misalignment is an exploitable thing, but you can definitely cause a segfault on any ctypes code, even if perfectly safe. Cheers, fijal
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4