* On 21 Jan 2015, Vincent Lefevre wrote:
> On 2015-01-20 15:08:52 -0600, David Champion wrote:
> > BE and LE may pack structs differently, but I believe members of a
> > union should have the same alignment even if of differing size. This
> > should be safe for byte transposition between a char[] and an int. (You
> > can't port the cache file across endianness, but that's true for other
> > reasons.)
>
> Couldn't the cache file be made architecture-independent?
>
> This could be useful for users working with a shared file system
> (such as NFS) on an heterogeneous network.
Agreed.
N.B. I could be wrong. I haven't checked the full code lately, this is
from memory and based on interpretation of the code in this patch.
I think there's room to improve (including extending hcache to mbox),
and if the cache is not portable it could in principle be made portable.
It would be a good change, but it needs a developer. :/
For the issue I pointed out in particular, using a union (or a type
cast, as before) is a technique for doing type conversions easily. To
do it portably we could instead use a packing loop:
for (i = 0; i < 4; i++)
packedint |= bytearray[i] << (8*i);
Not sure what other implications of such a change would be, or in
particular whether there's any problem with integer length in this.
(Could change to a uint32_t to get around that though.)
Come to think of it though, why do we care that hcachever is an
int? Why not store all 16 bytes of the md5 hash and eliminate this
messiness? It's not part of a timing- or performance-sensitive loop,
so we can spare a few cycles. The code would be more readable and more
maintainable.
--
David Champion • d...@bikeshed.us
