Could you please test the other suggested bn_lcl.h modification? While
you're on it...
>>> 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.
>> 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?
> and it is not related to mingw-win64, as this is needed
> also for NT port. There is too much dependency in ANSI in current
> implementation.
VC-WIN64* and VC-CE are compiled with UNICODE. It's supported option in
openssl.
> I forgot to mention that the uplink was removed due to assembly issues.
>
> There is another issue... sizeof(long)<sizeof(void*) in win64... So I found
> more places
> that needs some attention, the "Should be fixed" category probably impact
> more than
> I can fix. Alignments are simple to fix, but changing the long variables that
> hold pointers
> modifies interfaces.
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.
> I just don't understand how using Microsoft compiler this code makes
> sense.
It doesn't. It's just that casting of pointer to narrower type does not
necessarily constitute a bug (most notably when casted value is not
casted back to pointer) and as per above it was conscious choice in
time-pressed release situation. In addition one should note that gcc
makes you more nervous, because it's overzealous about pointer to
integer conversion even(!) with explicit casts. Most notably when you
say "I know what I'm doing" and write explicit
int foo(void *p) { return (int)p; }
MSC will respect your decision, while gcc will whine. If you reckon you
have to cast anyway, you'd be forced to (int)(size_t)p to get rid of gcc
warning.
> Works but cast need do be fixed:
> cryptlib.c:442: warning: cast from pointer to integer of different size
>
> printf, should be converted to %p and remove cast:
> asn1_lib.c:467: warning: cast from pointer to integer of different size
> mem_dbg.c:699: warning: cast from pointer to integer of different size
> bio_cb.c:78: warning: cast from pointer to integer of different size
>
> Should be fixed:
> mem_dbg.c:333: warning: cast from pointer to integer of different size
> rc4_enc.c:123: warning: cast from pointer to integer of different size
> rc4_enc.c:124: warning: cast from pointer to integer of different size
> b_print.c:379: warning: cast from pointer to integer of different size
> s3_pkt.c:146: warning: cast from pointer to integer of different size
> s3_pkt.c:688: warning: cast from pointer to integer of different size
> s3_pkt.c:701: warning: cast from pointer to integer of different size
This will be addressed in one way or another, but I can't say that I
agree with assertion that an interface needs to be changed. I'm not
saying that change is not an option! I'm only saying "feel free to
elaborate on assertion." A.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
