Thanks, I'd missed/forgotten that comment. I've also seen crashes in
single-threaded applications due to RAND_poll. One that immediately comes
to mind is when the performance counters in the registry are accessed which
cause hook DLLS to be loaded and called. I've come across a machine that
appe
You may want to see the threads:
BUG: CreateToolhelp32Snapshot
First (initializing) call to RAND_status() very slow on Win32
An excerpt:
Jeffrey Altman
Thu, 14 Aug 2003 11:23:38 -0700
The reason that we go to all this trouble to examine alternative sources
of randomness
other th
The non-thread-safe
nature of RAND_poll for Win32 is something I need to address as it's impossible
given the use of my library to expect RAND_poll to be called before other
threads exist. This leads me to the question of how good a random source
is the CryptGenRandom function on Windows.
NASM gives me some errors on compiling crypto\rc4\asm\r4_win32.asm:
.\crypto\rc4\asm\r4_win32.asm:30: operation size not specified
.\crypto\rc4\asm\r4_win32.asm:265: operation size not specified
.\crypto\rc4\asm\r4_win32.asm:267: operation size not specified
.\crypto\rc4\asm\r4_win32.asm:271: opera
Good catch. I think +r was favored over =&r for a reason [like bug in
initial gcc port, note that the code was written prior Opteron was
released], but I've tested now =&r with gcc 3.2 and it's treated
correctly. So I throw it in and syncronize HEAD and 0.9.7-stable. Case
is dismissed. A.
___
Hello All,
I find some unreachable codes in OpenSSL 0.9.7f . Their
details are as follows
Operating System : HPUX
OpenSSL Version : 0.9.7f
1. File : pk7_lib.c
Line: 187
break;
p7->d.signed_and_enveloped->enc_data->content_type
=OBJ_nid2obj(NID_pkcs7_data)
