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

  On Thu, Sep 17, 2015 at 12:58 PM, Roland McGrath <roland@hack.frob.com> wrote:
> If this matters it should break some linknamespace test.  If there is no
> reference from anything involved in the ISO C implementation, then there is
> no actual problem.
>
> For example, wordexp is a POSIX.1 function, so it referring directly to the
> public names of other POSIX.1 functions is not a problem.
>
> A change like this is not necessarily worthless even if it is not
> necessary.  But you haven't said why you think the change is desireable.
> If it makes is easier to understand or maintain the code overall, then that
> could be sufficient reason.  But you have to make some sort of positive
> case for a change.

Is this a valid test?
  

> 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).

AFAIK fmtmsg is only specified in standards that put all POSIX.1 symbols
(including pthread_setcancelstate) in the implementation name space.
  

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.

I don't know what combination of false positives and real problems you'd 
find if linknamespace.pl stopped special-casing weak symbols.

> 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.
  

> 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
  

On Thu, Sep 17, 2015 at 2:51 PM, Roland McGrath <roland@hack.frob.com> 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).
>
> AFAIK fmtmsg is only specified in standards that put all POSIX.1 symbols
> (including pthread_setcancelstate) in the implementation name space.

Does it mean it is OK for all most of, if not all,  non-ANSI C functions,
in glibc to use all POSIX.1 symbols? This is the usage of any non-ANSI C
functions may pull in any POSIX.1 symbols.
  

On Thu, Sep 17, 2015 at 2:57 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> 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.
>
> 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 it is a mistake to use weak symbols for this purpose.
  

On Thu, 17 Sep 2015, H.J. Lu wrote:

> On Thu, Sep 17, 2015 at 2:51 PM, Roland McGrath <roland@hack.frob.com> 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).
> >
> > AFAIK fmtmsg is only specified in standards that put all POSIX.1 symbols
> > (including pthread_setcancelstate) in the implementation name space.
> 
> Does it mean it is OK for all most of, if not all,  non-ANSI C functions,
> in glibc to use all POSIX.1 symbols? This is the usage of any non-ANSI C
> functions may pull in any POSIX.1 symbols.

Although most supported feature test macros in glibc are supersets of 
POSIX.1:1990, it's also the case that ISO C functions use lots of 
non-ISO-C functions via their implementation-namespace __* names - if an 
ISO C function uses __foo (strong name to which weak foo is a POSIX.1 
alias) then __foo can't use bar (non-ISO-C function) although it can use 
__bar.
  

> Does it mean it is OK for all most of, if not all,  non-ANSI C functions,
> in glibc to use all POSIX.1 symbols? This is the usage of any non-ANSI C
> functions may pull in any POSIX.1 symbols.

In general I would have said that's true.  But as Joseph pointed out, there
are standards we support, such as XPG4, that do not include all of recent
vintages of POSIX.1.  So I'd say it's still true for things in POSIX.1-1990
(notably not including pthreads).  And sometimes that's enough for it to be
completely obvious: anything outside outside ISO C can use read, write, and
close.  But byeond that it quickly becomes so picayune that I think we are
better off looking at the conform/data files rather than trying to use any
easy "rules of thumb" like this.