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...
Config knows about VOS and selects "no-threads no-shared no-asm no-dso".
Oh! You're the VOS guy! I have some questions to you, which I'll post off-list... If that's OK...
#if defined(__i386) || defined(__i386__) || defined(_M_IX86) || defined(__INTEL__) /* * *_block_host_order is expected to handle aligned data while * *_block_data_order - unaligned. As algorithm and host (x86) * are in this case of the same "endianness" these two are * otherwise indistinguishable. ... */ #define md4_block_data_order md4_block_host_order #endif
Maybe I don't understand this code as well as I thought, but the way I read this code, the algorithm is expecting data in LE order, and is presuming that Intel platforms also store data in LE order. That assumption is incorrect for our (admittedly rather unusual) platform. As coded, md4 fails on our BE Intel platform. When I recoded this #if statement to not be true, md4 worked. What am I missing?
Apparently nothing. I mean yes, you're right that in this place endianness is indeed assumed based upon compiler macro. It's just that I couldn't imagine, not even in a wildest dream, that someone would come up with idea to *emulate* big-endiannes at compiler level. I would actually even argue that in such case it's not appropriate for compiler to preserve __i386 macro, it should have defined __i386be or something... I mean I find it hard to believe that I would the only one, who would get an idea to make assumption about __i386 being little-endian...
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?
the compilers that we wrote or ported produce the necessary byte-swap instructions. All user-visible data in main memory is stored in big-endian format, and the compilers byte-swap when necessary.
Well, I wouldn't call it big-endian x86, as CPU still picks data in little-endian order. It's really a "WOW!" that you actually do it, but I wouldn't say "admittedly rather unusual," but "no doubt absolutely unique." So unique that you really shouldn't have preseved __i386 macro in your utterly special compiler, if you ask my opinion:-)
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...
OK, you're on.
You assert that tweaking those #if statements would help MkLinux(!) and I assert that it wouldn't.
I'll take a Sam Adams, please, if I'm right.
What's "Sam Adams"?
What's your pleasure?
I'm more realistic, so a postcard would suffice:-) A. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
