Unit tests of internal functions

[Ken Raeburn]

On Dec 28, 2009, at 15:11, ghudson at MIT.EDU wrote:
> 1. Just export those symbols, as we do in a number of cases already.

Exporting more symbols increases library size and reduces performance,  
though not a great deal in any individual case.  It also adds the  
possibility of an application either calling the function directly, or  
interposing its own version of the function, both of which I think it  
would be good to prevent.  (And if we want to allow interposition, we  
should discuss which functions can be replaced, and when we should  
call the externally visible and replaceable versions of functions  
versus internal, non-exposed ones, from other library routines.)

> 2. Make those symbols available through the accessor.  I would
> personally find this annoying, but it's a valid option.  This only
> really helps us in libkrb5, not for other libraries.  (We have
> libk5crypto symbols available in the accessor, but it's kind of silly
> since they currently have to be exported from libk5crypto to
> accomplish that.)

We could make a crypto-library accessor as well.  The accessor is  
awkward to use directly, but a helper file could be generated to  
simplify things.  (E.g., by defining static function pointers or  
functions or macros such that "foo()" in the test winds up actually  
calling internal function foo via the accessor.)

> 3. During make check, build a second version of each shared library
> with no restricted export list, and link test programs against that.

Or at least a much larger export list, including all the functions to  
be tested.

> 4. During make check, build static versions of each library and link
> test programs against that.  Zhana raised the objection that shared
> libraries should be tested as shared libraries, but I think that's
> only important for system tests (like the ones we have in
> tests/dejagnu), not unit tests.

Also relevant for performance testing, since PIC register use will  
affect register allocation, etc.  It also affects the handling of  
initialization/finalization code; system tests should catch most  
problems, but we might want to add tests someday to look for problems  
specifically in that code.

None of the options look particularly pretty, but in the interest of  
testing something that most closely resembles the code to be  
installed, I think I'd favor #2 or #3...

Ken