Re: MD5 checksum? Why? & mmap alignment on same machine in 32.v.64 mode

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Raimund Steger wrote:
From RFC1321:
"  The implementation is portable and should work on many different
   plaforms. However, it is not difficult to optimize the implementation
   on particular platforms, an exercise left to the reader. For example,
   on "little-endian" platforms where the lowest-addressed byte in a 32-
   bit word is the least significant and there are no alignment
   restrictions, the call to Decode in MD5Transform can be replaced with
   a typecast."

This means MD5 assumes the input data can be regarded as series of
little-endian int's. On platforms where it can't, a conversion step is
necessary. To avoid that, the implementation in the RFC reads the input
bytewise and shifts it into int's.

Colin Plumb's implementation, which fontconfig uses, seems to cast a char
buffer to an int one, mandating an endianness check.
----
   In other words, it appears that the shuffling routine should NOT
compiled-in on little-endian machines because of:

#ifndef HIGHFIRST
#define byteReverse(buf, len)    /* Nothing */

I.e. HIGHFIRST would be false on a little endian machine.  Yes?
I'm a bit rusty on my define macro expansion, but wouldn't


Second Q, the reason for needing separate caches has been described
as being due to the desire to mmap the cache files.

On x86_64 machines, when addressing the cache, if all types were
listed as being "[u]int{32,64}_t", when wouldn't the cache format
on such machines be identical whether you were running in 32-bit
or 64-bit mode?

I.e. it seems that when reading(or writing) values, you would explicitly
need to know that you needed a 32 or 64 bit quantity.  The only difference
between 32 & 64 bit modes that I know of is in regards to [unsigned]long [int],
where, at least in c++, it's a 64-bit size on x64 vs. 32-bit on x32.  I have
some vague remembrence that a [uns]long-int in 'C' is 32-bits in both
on some OS's (don't remember if it was MS-only or both MS+linux && no-idea
on Mac). Either way, wouldn't it be the case that one size (32 or 64) would be needed, so referring to data members with the bitsize should result in identical
mmap'ed structures on x86_64 whether you are running in 32 or 64
bit mode?

Wouldn't that require using only 1 cache on those machines?

tnx,
Linda

_______________________________________________
Fontconfig mailing list
Fontconfig@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/fontconfig




[Index of Archives]     [Fedora Fonts]     [Fedora Users]     [Fedora Cloud]     [Kernel]     [Fedora Packaging]     [Fedora Desktop]     [PAM]     [Gimp Graphics Editor]     [Yosemite News]

  Powered by Linux