| Message ID | CAMe9rOrGYk6s94vvSVC1R7uBS-qGZaH8Pdwr62G+ZZdgnLKeig@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
> 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.
diff --git a/stdlib/Makefile b/stdlib/Makefile index 402466a..c99ad73 100644 --- a/stdlib/Makefile +++ b/stdlib/Makefile @@ -74,8 +74,8 @@ tests := tst-strtol tst-strtod testmb testrand testsort testdiv \ tst-makecontext3 bug-getcontext bug-fmtmsg1 \ tst-secure-getenv tst-strtod-overflow tst-strtod-round \ tst-tininess tst-strtod-underflow tst-tls-atexit \ - tst-setcontext3 tst-tls-atexit-nodelete -tests-static := tst-secure-getenv + tst-setcontext3 tst-tls-atexit-nodelete tst-fmtmsg-static +tests-static := tst-secure-getenv tst-fmtmsg-static modules-names = tst-tls-atexit-lib diff --git a/stdlib/tst-fmtmsg-static.c b/stdlib/tst-fmtmsg-static.c new file mode 100644 index 0000000..60e6642 --- /dev/null +++ b/stdlib/tst-fmtmsg-static.c @@ -0,0 +1 @@ +#include "tst-fmtmsg.c" diff --git a/stdlib/tst-fmtmsg.c b/stdlib/tst-fmtmsg.c index b7948c5..de8d16a 100644 --- a/stdlib/tst-fmtmsg.c +++ b/stdlib/tst-fmtmsg.c @@ -81,5 +81,11 @@ do_test (void) return result; } +int +pthread_setcancelstate (int *p) +{ + return p[0]; +} + #define TEST_FUNCTION do_test () #include "../test-skeleton.c"