This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Untested symbols
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: <libc-alpha at sourceware dot org>
- Date: Fri, 26 Jul 2013 17:03:04 +0000
- Subject: Re: Untested symbols
- References: <Pine dot LNX dot 4 dot 64 dot 1307192154240 dot 14156 at digraph dot polyomino dot org dot uk> <20130720034539 dot GA5718 at domone> <Pine dot LNX dot 4 dot 64 dot 1307201043040 dot 3231 at digraph dot polyomino dot org dot uk> <20130726141129 dot GA12217 at domone dot kolej dot mff dot cuni dot cz>
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