Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 11 Nov 2013 23:41:29 -0500
From: Rich Felker <>
Subject: Re: 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


> 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

> 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


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.