Re: libc.so symbols that are not reserved

[Rich Felker <dalias@aerifal.cx>]

On Tue, Nov 12, 2013 at 05:07:36AM +0100, Szabolcs Nagy wrote:
> > 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

Interesting...wonder why I did that one but not pipe2...?

> so the only exceptions are
> 
> pipe2

Known.

> stdin
> stdout
> stderr

Pending interpretation from WG14. :-)

> getservbyname_r
> getservbyport_r

Indeed. I must have been mistakenly thinking getservbyname and
getservbyport were obsolete already, but they're not even marked
obsolescent, despite getaddrinfo and getnameinfo offering replacement
functionality that's actually thread-safe and clean. The failure to
shade these functions [OB] perhaps should be reported as a bug against
POSIX.

> if pipe2 and dup3 are in the next standard then i dont think
> they have to be weak

Yeah, I'm fairly indifferent on it too, but I'll change them if anyone
complains.

Rich