[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 11 Nov 2013 23:41:29 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: libc.so symbols that are not reserved
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
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.
