Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 12 Nov 2013 05:07:36 +0100
From: Szabolcs Nagy <>
Subject: Re: symbols that are not reserved

* Rich Felker <> [2013-11-11 21:55:40 -0500]:

> On Tue, Nov 12, 2013 at 02:39:47AM +0100, Szabolcs Nagy wrote:
> > i filtered nm -D 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


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.