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.