On 10/31/08, Andy Polyakov via RT wrote:
> Could you please test the other suggested bn_lcl.h modification? While
> you're on it...

I cannot actually test it... I can compile and users may test.
I don't have a win64 machine.
And I don't know how exactly I can check for speed...
I can send you binaries to test if you like.

> >>> I am not fully sure that the crypto/sha/sha512.c is correct, it
> >>> simulate the behavior of win64 using Microsoft compiler, using
> >>> _rotr64 function as ROTR.
> >> What you should have done instead is to modify macro in question
> >> declaring ret as unsigned long long. If it doesn't work, then it's more
> >> appropriate to leave ROTR undefined, i.e. *not* using _rotr64. Please
> >> verify.

> >
> > Thanks, I converted this to SHA_LONG64 and it now compiles.

> Can you confirm that it even passes the test? I mean mere compilation
> success doesn't qualify, it has to pass the test.

I will ask my users to run the sha512 test.

> >> Also. As NT is natively UNICODE, and there are no non-NT Win64
> >> implementations(*), there is no reason to favor legacy ANSI interfaces.
> >> Could you verify that it compiles and works with -DUNICODE -D_UNICODE
> >> added to config line?

> >

> > This is too much work,

> Adding couple of words to config line?

I tried to... But then got many linkage error messages of _OBJ_ something.
Strange... Now I tried it on clean tree with same snapshot and it compiles.
Except one modification I had to do, updated in the patch.

> Quoting util/VC-32.pl: "As per 0.9.8 release remaining warnings were
> explicitly examined and considered safe to ignore." It naturally does
> not necessarily apply to HEAD, but there is awareness of the problem.

Well... I don't run this script

Attached is a new patch.