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@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org