[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131112040736.GQ1685@port70.net>
Date: Tue, 12 Nov 2013 05:07:36 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: libc.so symbols that are not reserved
* Rich Felker <dalias@...ifal.cx> [2013-11-11 21:55:40 -0500]:
> On Tue, Nov 12, 2013 at 02:39:47AM +0100, Szabolcs Nagy wrote:
> > i filtered nm -D libc.so for posix name space violations
> > and compared the results (weak symbols were omitted), some
> > of these should be fixed
>
> I'm unclear on why you consider them violations. They do not conflict
> with symbols in the application or in third-party libraries. This can
> easily be verified. Basically, symbols in shared libraries always act
> like weak symbols would in static linking (this may be a poor
> approximation of the reality, but it's close enough to be a useful way
> of thinking about it).
ok i didnt think it through
> What would in principle be problematic is if standard C or POSIX
> functions in libc depended on any of these symbols, since an
> application could interpose unrelated functionality with the same
> name. In practice that doesn't matter for dynamic linking since
> -Bsymbolic is used, but it would matter for static linking of course.
> As far as I know musl has no such issues (except for treating dup3,
> pipe2, etc. as if they were in POSIX since they will be in the next
> issue; if you object to that I'm not opposed to adding __-prefixed
> versions).
actually dup3 is __ prefixed already
so the only exceptions are
pipe2
stdin
stdout
stderr
getservbyname_r
getservbyport_r
if pipe2 and dup3 are in the next standard then i dont think
they have to be weak
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.
