>>>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 majordomo@openssl.org