For legacy and compatibility reasons I have to use an older version of the
Windows DDK to compile certain libraries, including OpenSSL. I am
compiling it with version 3790.1830.
In other words compiler version 13.x.
I spent the morning tracing a crash in BN_nist_mod_384 which I believe is
You make it sound like the fact that c_d is a stack array is an excuse
for doing wrong:-) I mean it's clearly a compiler bug and reasoning as
above does not make it understandable/justifiable/excusable. Formally
it's not OpenSSL bug and shouldn't be reported as one...
I thought I'd made it
You make it sound like the fact that c_d is a stack array is an excuse
for doing wrong:-) I mean it's clearly a compiler bug and reasoning as
above does not make it understandable/justifiable/excusable. Formally
it's not OpenSSL bug and shouldn't be reported as one...
I thought I'd made
It works. The new assembler is:
LEA eax,[c_d]
MOV DWORD PTR [res],eax
MOV ecx,DWORD PTR [mask]
NOT ecx
AND ecx,DWORD PTR [res]
MOV edx,DWORD PTR [r_d]
AND edx,DWORD PTR [mask]
OR ecx,edx
MOV DWORD PTR [res],ecx
The addition of the LEA instruction gets the pointer value from c_d instead
of its
It works.
In all subroutines? Could you double-check? The reason for being
overparticular is that when it comes to compiles bugs, one can expect
*anything*.
Note that you forgot to add it to the BN_nist_mod_521() function, probably
because the variable is named t_d in that function instead of
For legacy and compatibility reasons I have to use an older version of the
Windows DDK to compile certain libraries, including OpenSSL. I am
compiling it with version 3790.1830. My main project (the one that links
against OpenSSL) is compiled in Visual Studio 2010.
I spent the morning tracing a
