[erlang-questions] crypto NIF vs OpenSSL problems

Per Hedeland <>
Tue Mar 1 08:31:34 CET 2011

Sverker Eriksson <> wrote:
>Per Hedeland wrote:
>> Hi,
>> Pre-R14, if libcrypto was missing / wrong version,
>> application:start(crypto) would return a nice error (well, at least an
>> error). crypto:start() would return the same error.
>> With the same scenario in R14, application:start(crypto) succeeds(!),
>> and crypto:start() crashes with undef. I understand completely why on
>> both counts, but, um... - is this intentional? Or a bug (or two) that
>> will be fixed
>Maybe you could say that application:start(crypto) succeeding is a bug 
>and it should fail with nice error as before.

Yes, at least some failure indication would be appropriate I think -
it's rather weird to have application:start() succeed even though *any*
use of the application will fail. Of course (with the current crypto
design) this can be easily achieved by having application:start/0
attempt to load the crypto module - e.g. a silly call of
crypto:version/0 from crypto_server:init/1 does the trick.

>I don't think I want to revert the behavior of crypto:start() as that is 
>"clearly undocumented" and undef is what you get when trying to call a 
>function in module that can not be loaded.

Yes, you're probably right - undef is kind of "logical" (and it's
certainly true that the module couldn't be loaded). And now you have the
nice (though also undocumented:-) feature that you can just call any
function in crypto without bothering with either type of start - it
would be non-backwards-compat to lose that.:-)

Hm, thinking about a way to do the latter without the use of on_load -
would it be useful to have some "magic" to let a NIF stub work a la
error_handler:undefined_function/3? You could of course do it "manually"
with something like

md4(Data) -> load_the_nifs(md4, [Data]).
md4_init() -> load_the_nifs(md4_init, []).

and so on, but this would obviously be both boring and error-prone.


More information about the erlang-questions mailing list