> appro> I managed to reproduce the problem under nue (IA-64 emulator for Linux)
> appro> and with gcc 2.96 (the one found in nue-fs-1.2-1). It's a compiler bug:
> appro>
> appro> *** ./crypto/asn1/a_d2i_fp.c.orig Sun Nov 24 18:14:40 2002
> appro> --- ./crypto/asn1/a_d2i_fp.c Sun Nov 24 18:15:16 2002
> appro> ***************
> appro> *** 149,155 ****
> appro> ASN1_CTX c;
> appro> int want=HEADER_SIZE;
> appro> int eos=0;
> appro> ! int off=0;
> appro> int len=0;
> appro>
> appro> b=BUF_MEM_new();
> appro> --- 149,155 ----
> appro> ASN1_CTX c;
> appro> int want=HEADER_SIZE;
> appro> int eos=0;
> appro> ! size_t off=0;
> appro> int len=0;
> appro>
> appro> b=BUF_MEM_new();
>
> Uhmm, I'm sorry, exactly what kind of difference does that make?
It's a compiler bug, it doesn't have to make any sense whatsoever.
> Since it's otherwise used with ints (len and i, mostly), and size_t
> usually is unsigned, that becomes quite a mix of unsigned vs. signed.
size_t is not necessarily an appropriate choice. The point is rather
that off has to be declared 64-bit (long will do *as* *well* as size_t)
and not 32-bit.
> appro> *** ./crypto/aes/aes_cbc.c.orig Sat Nov 23 00:16:50 2002
> appro> --- ./crypto/aes/aes_cbc.c Sun Nov 24 14:54:31 2002
> appro> ***************
> appro> *** 64,70 ****
> appro> unsigned char *ivec, const int enc) {
> appro>
> appro> unsigned long n;
> appro> ! unsigned long len = length;
> appro> unsigned char tmp[AES_BLOCK_SIZE];
> appro>
> appro> assert(in && out && key && ivec);
> appro> --- 64,70 ----
> appro> unsigned char *ivec, const int enc) {
> appro>
> appro> unsigned long n;
> appro> ! long len = length;
> appro> unsigned char tmp[AES_BLOCK_SIZE];
> appro>
> appro> assert(in && out && key && ivec);
>
> Same problem.
Same explanation. Compilere bugs seldom make sense. In this particular
situation it has to be signed. ecc 5.0.1 is probably not so interesting
anyway... And it disappears at lower optimization level...
> In any case, if those are caused by compiler bugs, I'd say that the
> compiler in question is automagically rejected and needs to be fixed.
> I can't see that there's any excuse to change OpenSSL's code because
> the compiler is buggy...
Note that I'm *not* nominating these patches, just so to say lifting up
the problem.
> And yes, you're right, there are other problems, especially in Windows
> 64bit,
Do you have access to Win64 machine? Is assembler module engaged? If not
we can discuss it through...
A.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
