Riccardo,

>>it is nice to see how my messages are totally ignored...


As nice as to see how instructions in ./README are totally ignored:

"
SUPPORT
-------

If you have any problems with OpenSSL then please take the following
steps first:

- Download the current snapshot from ftp://ftp.openssl.org/snapshot/
to see if the problem has already been addressed
- Remove ASM versions of libraries
- Remove compiler optimisation flags

"

>>I hope this
>>doesn't mean that everybody is clueless.


Clues? Google for 3c48692aceb44f85cf99c985154c15b79e6baef0, which is
your own hash value... gcc-bugs report from 2000 maintains that gcc 2.96
fails in exactly same way on PowerPC, but not 2.95.3... Does it sound
like problem with test program? No, it sound like compiler bug...

Paul,

> With the wide variety of platforms, it is not unusual for problems to show
> up on only one platform.


Yes, but when it does, it's more and more likely to mean that it's
something wrong with end-developer environment, e.g. a compiler bug...
Naturally provided that platform is correctly recognized by ./config...

> I had a similar problem with MD4, MD5, RIPEMD and SHA on my system because
> some of the OpenSSL source code assumes that certain platforms have certain
> endian characteristics. In my case, the code tested the _i386 macro and
> decided the platform must be little endian.


This is wastly misleading. Endianess assumptions are based upon
-D[LB]_ENDIAN macro in corresponding ./Configure line, not upon CPU
macros set up by compiler. Well, assembler code does assume endianess
[naturally!], so that if you get rid of -D[LB]_ENDIAN [or change it],
you better configure with no-asm. Also note that [LB]_ENDIAN is
essentially a performance option and the code works correctly without it.

> As it happens, I have a
> big-endian environment on an Intel box,


Is it really possible? Is there an x86 big-endian? Is it possible to
switch Intel x86 to big-endian? What OS does it run? Which config line
does OpenSSL picks then?

> I presume that a PPC is a PowerPC, which is also a big-endian platform.


PowerPC processor is capable of operating in either mode, so that
*formally* you can't assume endianess based solely on the fact that it's
PowerPC-based. The switch is software initiated and is commonly
performed by kernel bootstrap loader. Well, "commonly" is a bit
misleading, because Windows NT and Solaris were the only ones I'm aware
of [yes, there was NT for PPC and there was Solaris for PPC], which
would switch to little-endian mode. Meaning that it's rather safe to
assume that it's big-endian, as long as we're talking about a "commodity
"platform, but not if we discuss some embedded one.

> Take a close look at some of the #if macro tests in, for example,
> crypto/sha/sha_locl.h. You could be hitting a similar problem.


I bet not:-) As mentioned, it smells a compiler bug...

> We found the problem by one of our programmers having a brilliant insight,


You could as well just stick to instructions in ./README to get rid of
assembler and examine line in ./Configure to spot -DL_ENDIAN and realize
it's not appropriate in your case. You didn't actually have to modify
the source code. A.
__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org