This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] [BZ #18970]: Reference of pthread_setcancelstate in libc.a


> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]