> I wouldn't do it like that.  You are executing a function call
You've mentioned "a function to detect" yourself, haven't you:-)
> and all that is requrired is a simple test.
Of course! In real life you would *inline* whatever the function does.
> 
> I'd do it something like this probably:
> 
> static union endian
>    {  int i;
>       char little;
>    } is_endian;
> 
> Then in an initializationb routine:
> 
> is_endian.i = 1
But if you declare it const and initialize it at compile time instead,
then the compiler gets a chance to at least generate correct branch
prediction flag and in the best case even eliminate none-relevant code
fragment along with the branch itself:-)

Now back to your previous letter:
> So all I'll need are the names of a couple affected functions.
As I already mentioned it's 32-bit block message digests, i.e. MD5, SHA*
and RIPEMD160, and updated RC4 (first available in 19990927 snapshot).
Affected functions are HASH_UPDATE in ./crypto/md32_common.h and RC4 in
./crypto/rc4/rc4_enc.c. Note that HASH_UPDATE itself is endian-neutral!
As well as HASH_BLOCK_DATA_ORDER and HASH_BLOCK_HOST_ORDER! #ifdef
[LB]_ENDIAN appears earlier when you "alias"
HASH_BLOCK_DATA_ORDER_ALIGNED to HASH_BLOCK_HOST_ORDER whenever host
happens to be of the same endianness as input data. It's (as already
mentioned) done for performance sake. But I have to admit that in this
case (message digests) it's perfectly possible to implement check for
endiannes at run-time without sacrificing performance *or* space. In RC4
case you *have to* make the code *substantially* bigger if you want to
keep performance. Fortunately RC4 is rather compact and extra 1.5
kilobyte (of machine code and only if compiler fails to eliminate it:-)
won't harm anybody... I'll look into the whole thing...
> I'll need the current sourse tree
Which is always available at ftp://ftp.openssl.org/snapshot/.

Andy.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to