crypto NIF vs OpenSSL problems

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

crypto NIF vs OpenSSL problems

Per Hedeland
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?

Thanks
--Per Hedeland

________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: crypto NIF vs OpenSSL problems

Sverker Eriksson
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.

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.

/Sverker




________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: crypto NIF vs OpenSSL problems

Per Hedeland
Sverker Eriksson <[hidden email]> 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.

--Per

________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]