generic-library/openssl
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Don't initialise the pointers to mutex functions directly in the structure.

Browse Source 
This is correctly taken care of by hwcrhk_init().  While we're at it, give
this engine the official name of the library used (CHIL, for Cryptographic
Hardware Interface Library).
This commit is contained in:
Richard Levitte 2000-07-05 16:00:18 +00:00
parent e1e9ead6fb
commit f3052a9eee
1 changed files with 10 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
crypto/engine/hw_ncipher.c
View File

@ -155,7 +155,7 @@ static RAND_METHOD hwcrhk_rand =
/* Our ENGINE structure. */
static ENGINE engine_hwcrhk =
{
"hwcrhk",
"chil",
"nCipher hardware engine support",
&hwcrhk_rsa,
NULL,
@ -233,14 +233,16 @@ static HWCryptoHook_InitInfo hwcrhk_globals = {
0, /* Max simultaneous, 0 = default */
/* The next few are mutex stuff: we write wrapper functions
round the OS mutex functions.
Currently, the support in OpenSSL is just not good enough,
so this part is currently skipped, but worked on. */
around the OS mutex functions. We initialise them to 0
here, and change that to actual function pointers in hwcrhk_init()
if dynamic locks are support (that is, if the application
programmer has made sure of setting up callbacks bafore starting
this engine). */
sizeof(HWCryptoHook_Mutex),
hwcrhk_mutex_init,
hwcrhk_mutex_lock,
hwcrhk_mutex_unlock,
hwcrhk_mutex_destroy,
0,
0,
0,
0,
/* The next few are condvar stuff: we write wrapper functions
round the OS functions. Currently not implemented and not