seg fault in crypto.h code
Nikos Mavrogiannopoulos
n.mavrogiannopoulos at gmail.com
Mon Apr 28 17:21:43 CEST 2008
Simon Josefsson wrote:
> The problem I see is that libgnutls could be used by libraries, and they
> may not be aware of each other. Consider:
>
> threaded application
> ---> library 1
> -> register a crypto.h handler
> -> gnutls_global_init
> ---> library 2
> -> register a crypto.h handler
> -> gnutls_global_init
>
> I'm not sure what the expected behaviour should be in this situation.
> Any crashes should be avoidable, of course, but it may be (too?)
> surprising for library 1 to not use the crypto.h functions it
> registered.
Each one registering a handler, associates with a priority number. On
execution time the one with lowest priority is run. In case of a
conflict (priority number reuse or registering with higher priority than
an existing handler) the registration will fail.
> This was my reason for doing a compile-time (rather than run-time)
> decision via the gnulib gc-* stuff, but alas that was never finished for
> pk/mpi.
The approach I followed in pk/mpi will allow for both compile time and
runtime decision. Once finished I'll rewrite the logic in
hash/cipher/rnd to be similar in mind.
More information about the Gnutls-devel
mailing list