[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5354FDFE.5030809@midipix.org>
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.
