[PATCH] [BZ #18970]: Reference of pthread_setcancelstate in libc.a
Roland McGrath
roland@hack.frob.com
Thu Sep 17 22:03:00 GMT 2015
> On Thu, 17 Sep 2015, Roland McGrath wrote:
>
> > > Is this a valid test?
> >
> > No. There should be no need for individual tests like that. The
> > linknamespace tests should catch such things if the conform data is correct
> > (and if it's not, the right thing is to fix the conform data).
>
> See one of the caveats listed in linknamespace.pl:
>
> # * Weak undefined symbols are ignored; however, if a code path that
> # references one (even just to check if its address is 0) is executed,
> # that may conflict with a definition of that symbol in the user's
> # program.
Ah. That is something to be concerned with.
That being the case, HJ's test is probably about right (but needs comments).
> I don't know what combination of false positives and real problems you'd
> find if linknamespace.pl stopped special-casing weak symbols.
I think we should look into that. The name space issues are orthogoal to
weakness in all scenarios I can think of. If code reached by function foo
is affected at all by a symbol bar and bar is in the application name space
for some application that can use foo, then there is a problem.
> > AFAIK fmtmsg is only specified in standards that put all POSIX.1 symbols
> > (including pthread_setcancelstate) in the implementation name space.
>
> fmtmsg is in XPG4, which doesn't have pthreads.
In that case the fix is actually necessary. Thanks for pointing that out.
Thanks,
Roland
More information about the Libc-alpha
mailing list