Re: Untested symbols

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

On Fri, 26 Jul 2013, Ondrej Bilka wrote:

> On Sat, Jul 20, 2013 at 11:03:57AM +0000, Joseph S. Myers wrote:
> > 
> > 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.)
> >
> 
> The 916 tests is still too much to add manually. You need some

No more so than 627 open bugs are too much to fix manually - the typical 
function is rather simpler to add sensible tests for than the typical bug 
is to fix.  In both cases we still have the problem of attracting more 
contributors to glibc, but both are very accessible to incremental fixing, 
one bug or one test at a time.

> automation to reduce it. Best way is find some classes that can be
> handled uniformly.
> 
> As you mentioned only test if they compile and link it should be
> possible to get prototype and supply default arguments for each type.

For the functions that can't be tested meaningfully, sure, such automation 
may help in creating the tests (tests still need to go in appropriate 
directories, sysdeps if the function is e.g. Linux-specific).  But 
actually two of the four examples I gave *can* have the execution of a 
call tested - you can setuid to your own uid, and chown a file you own 
with arguments -1, -1 not to change anything (or, I think, with the owner 
and group the file already has explicitly specified).  The amount that 
tests is limited, but it does verify that a call executes OK (so there 
isn't a fatal flaw in some syscall implementation .S file, for example), 
which seems useful.

-- 
Joseph S. Myers
joseph@codesourcery.com