Re: libc.so symbols that are not reserved

[Rich Felker <dalias@aerifal.cx>]

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).

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).

Rich