[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