Date: Mon, 21 Apr 2014 07:16:14 -0400 From: "writeonce@...ipix.org" <writeonce@...ipix.org> To: musl@...ts.openwall.com Subject: Re: static musl-based gdb and -fPIC On 04/21/2014 03:33 AM, Szabolcs Nagy wrote: > * writeonce@...ipix.org <writeonce@...ipix.org> [2014-04-20 17:39:37 -0400]: >> For the record: python's Modules/posixmodule.c has a static >> implementation of posix_close that is incompatible with musl's. My > yes they define posix_ prefixed symbols for internal use > which are reserved names for the c implementation when > any standard headers are included > > the next posix standard defines posix_close so this is a > real collision (and will be an issue with every conformant > libc), but all the other posix_ symbols are wrong there too > >> first take on that was to make python use musl's posix_close, which >> resulted in a very subtle bug leading to a segmentation fault (not >> to mention all of those lost hours...) Renaming the module's >> posix_close to __posix_close solved the problem. The code that > these functions have nothing to do with libc: they operate on > python objects > > the symbols should be just renamed but your solution is wrong: > the __ prefix is still in the reserved name space > > use s/posix_/pyposix_/ or similar > > Thanks for pointing this out. I guess Py_posix_close would be closest in spirit to the rest of the python code.
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.