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
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. */ /* Our ENGINE structure. */
static ENGINE engine_hwcrhk = static ENGINE engine_hwcrhk =
{ {
"hwcrhk", "chil",
"nCipher hardware engine support", "nCipher hardware engine support",
&hwcrhk_rsa, &hwcrhk_rsa,
NULL, NULL,
@@ -233,14 +233,16 @@ static HWCryptoHook_InitInfo hwcrhk_globals = {
0, /* Max simultaneous, 0 = default */ 0, /* Max simultaneous, 0 = default */
/* The next few are mutex stuff: we write wrapper functions /* The next few are mutex stuff: we write wrapper functions
round the OS mutex functions. around the OS mutex functions. We initialise them to 0
Currently, the support in OpenSSL is just not good enough, here, and change that to actual function pointers in hwcrhk_init()
so this part is currently skipped, but worked on. */ 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), sizeof(HWCryptoHook_Mutex),
hwcrhk_mutex_init, 0,
hwcrhk_mutex_lock, 0,
hwcrhk_mutex_unlock, 0,
hwcrhk_mutex_destroy, 0,
/* The next few are condvar stuff: we write wrapper functions /* The next few are condvar stuff: we write wrapper functions
round the OS functions. Currently not implemented and not round the OS functions. Currently not implemented and not