Re: Untested symbols

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Sat, 20 Jul 2013, Ondrej Bilka wrote:

> > The list include reserved-namespace symbols.  This is deliberate.  For 
> > each such symbol, if there is a good reason for it to be in the public ABI 
> > (for example, for namespace-clean use in libstdc++ or libgcc, or because 
> > it is used by a public macro in an installed header), then it should be 
> > tested (if it's used via a macro, that macro should be tested as the 
> > interface actually exposed to users).  If there is no such good reason,
> 
> Could you elaborate why? Among list is most of string, malloc, ctype functions 
> with __ prefix. Creating files that duplicate test for normal symbol is
> just pointless.

If a symbol is part of the public interface, even if only for 
libstdc++/libgcc, glibc tests should verify that the symbol works 
properly.  Such tests can of course #include another test with some extra 
#defines, for example, if that's the most convenient way of testing a 
symbol without duplication of test source code.

> Then there are math_finite symbols which are false positives.

No, they are not false positives.  There is no test coverage for libm with 
-ffinite-math-only.  This allowed alpha to have a few releases where calls 
to sqrt functions with -ffinite-math-only would not have worked.

Part of the point of adding such test coverage is to ensure such problems 
- architecture-specific missing symbols that are meant to be part of the 
public API - get detected without getting into releases.

> Also for _IO_* could be generaly make private.

Quite likely.  Each reserved-namespace symbol in the list requires 
separate investigation to determine whether it should have tests added, or 
whether it should be made a compat symbol so newly linked programs cannot 
use it - this is a choice for the person working on each individual symbol 
to make and justify with an analysis included in their patch posting.  
(In some cases, symbols made into compat symbols may also need a 
GLIBC_PRIVATE version added, if there is good reason for other glibc 
libraries to use a reserved-namespace version but not for code outside of 
glibc to do so.)

> You need to clean that list more to be useful.

The way to clean the list of reserved-namespace symbols is to examine them 
one-by-one manually and make them into compat symbols in glibc if they 
don't need to be public interfaces - or, as applicable, to add testcases 
(running the relevant parts of the libm tests with -ffinite-math-only, for 
example).

> > Certainly adding tests of all these functions (which should generally try 
> > to test that the main functionality of the interface works as specified, 
> > rather than just that the function exists) will be a lot of work, but it 
> > can be done a little bit at a time (and in many cases, making a function 
> > into a compat symbol may be the right approach).  I fully expect various 
> > bugs, both generic and architecture-specific, will be found in the 
> > process.
> > 
> More appropriate question is if this work is worth pursuing. For
> testing that interface exist you duplicate tests that are implicitly
> present in our testsuite by calling nonreserved symbols.

In general the tests are *not* present.  As another example, consider how 
fallocate64 was missing on 32-bit architectures in 2.10.  It is still the 
case that the glibc testsuite has no test coverage for fallocate64, so it 
appears in this list of untested symbols.

Anyway, you can ignore the reserved-namespace symbols if you wish.  That 
reduces 1493 untested symbols (some in more than one library) to 916.  
The bulk of those are symbols that could have genuine, meaningful tests of 
their functionality added.  It's extremely easy for people interested in 
adding tests to find good functions to test in the list - we're a very 
long way from the point where it's largely adding skeleton tests that 
confirm that functions such as chown, delete_module, reboot or setuid 
exist without being able to verify much more about those functions.  (But 
I still wouldn't recommend *removing* such functions from the list - 
better to add the minimal tests to verify that calls compile and link, so 
that no-one creates a glibc port that's accidentally missing them.  Such a 
minimal test of a root-only function is quick to add.)

-- 
Joseph S. Myers
joseph@codesourcery.com