[libvirt] [PATCH] Replace hashing algorithm with murmurhash

Eric Blake eblake at redhat.com
Wed Jan 25 17:16:05 UTC 2012


On 01/25/2012 09:55 AM, Eric Blake wrote:
>>>> +
>>>> +    return le32toh(r);
>>>
>>> <endian.h>, and thus le32toh(), is not yet standardized (although POSIX
>>> will be adding it in the future), nor is it currently provided by
>>> gnulib.  We'd have to get that fixed first.
>>
>> The le32toh call was only here because the code I copied wanted to be
>> endian neutral. I don't think libvirt really cares if its hash codes
>> are endian neutral, so I trivially just removed the le32toh call and
>> avoid the problem of endian.h
> 
> Agreed - we aren't sharing hash values over the wire, so all hash values
> within a particular libvirtd process will be the same endianness,
> without having to waste time on swapping bytes around.

Actually, the more I think about this, the more I have to wonder:  Does
the incoming alignment affect the output hash?  That is, if I do

int i;
char array[12];
for (i = 0; i < 4; i++) {
    strcpy(array + i, "12345678");
    printf("%x\n", (int) virHashStrCode(array + i, 0));
}

do I get the same values for all four iterations, on both little- and
big-endian architectures?  If not, then the byte-rearranging really is
important to the algorithm (that is, the algorithm is operating on
4-byte quantities, but must build up those quantities from 1-byte
quantities regardless of starting alignment, so endianness looks like it
plays a role in doing the conversion correctly).

-- 
Eric Blake   eblake at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120125/cd3f3ec5/attachment-0001.sig>


More information about the libvir-list mailing list