Michael Richardson <mcr@sandelman.ottawa.on.ca> writes:
>     Chris> * running such programs on a system with the fake library.  In
>     Chris> general, it's not desirable to have a core dump because a stub wasn't
>     Chris> implemented.  (if this is all the reliability you want, just let the
>     Chris> linker's lazy binding go boom when the symbols are used!)
> 
>   In the case of RSA used in ISAKMP, if the user has configured to enable RSA
> and they don't have it, then it goes boom. Sure, I can just let the linker go
> boom, that's true, but I would think that the binary would complain if we had
> no library at all, correct? Perhaps we want to have better diagnostics. Depends.

I dunno.  I'm pretty sure the dynamic linker will complain (and fail)
at program startup if it can't find a shlib the program needs.

in any case, the run-time "goes boom" should _not_ cause the program
to crash or otherwise exit ungracefully.  If it does that, then, from
the user's perspective, the program is broken.  (further, who knows
what actual nasty side effects just exiting from an unimplemented
stub, either via exit() or abort() would have.  I.e. it might leave a
bunch of bad state around, that the program would have cleaned up
before exiting.)

In other words, if you're going to try to provide this type of
library, you _really_ need to provide a way to dynamically determine
what's there (or make sure code knows to use dlsym() to see what's
there).


>     Chris> If the intent is to both build and run the programs on a system with
>     Chris> 'real' implementations of the functions that are stubbed in the
>     Chris> library, what use is the library of stubs?  8-)
> 
>   I want to permit people to write code that *might* want to use RSA, but can
> cope with DSA, and if the end user obtains an RSA library that is legal for
> their use (compiles RSAREF in the US with appropriate licensing, which many
> research places already have), then it just works. Yes, one could make the
> code compile depending on HAVE_RSA or something.

So, this implies that it can tell in a non-fatal way whether code's
there.  You never described anything like that in your initial mail.

Instead of saying that you want a shared library which contains stubs
for a bunch of crypto functions, you _reall_ should be more specific
about what you're talking about.



>     Chris> I'd actually think that a better alternative to that (if a 'standard'
>     Chris> API to do things like this doesn't already exist) would be having the
>     Chris> application try to dlopen() modules which contain the crypto
>     Chris> algorithms it wants to use.  That way:
> 
>   Yes. I really hate explicit dlopen() because it makes building with -static
> a pain in the butt.

Really, it makes building with -static impossible.  8-)


>     Chris> Note that you're already assuming a shared library, so you're already
>     Chris> presuming dynamic linking capability...
> 
>   But, not depending upon it.

There's no point in having a library of do-nothing (or 'just croak if
called') stubs at all, if you're not talking about a dynamically
linked program.  (the user can never substitute them for something
better, and they'll always crash.)

That's all you've said you want to provide in your "stubs" library.


So:

What, specifically, do you want to provide in such a library?



cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.