Fix Endianness / portability ?

[dhardy]

I notice that this uses the simplest implementation of Hasher possible. Functions like write_u16 cast multi-byte numbers to byte-slices without fixing Endianness; this implies one should get different results on Big Endian vs Little Endian machines.

I don't know whether this is the only portability issue (e.g. I don't know if there are any complications if the bytes supplied to write are not sufficiently aligned; presumably only performance).

Now, I'm not sure whether to call the lack of Endianness fixing in Hasher default function impls a bug in the standard library or not, but it's a problem for our use-case (not certain whether we will use MetroHash yet). We could simply wrap with HasherToLE (endian-hasher), but that seems messy.

Your thoughts?

[arthurprs]

It may be a matter of adding some to_le() to the read functions in utils.rs. Not all hashers are portable so I'd say the Hash trait is fine.

Is there any easy way of testing such things in a x64 laptop?

[dhardy]

Best option may be cross-compiling on Travis (see trust; you can remove parts of the .travis.yml script, e.g. deployment), and unit tests.

[dhardy]

I think fixing Endianness is mostly about calling .to_le() in the Hasher functions as here.

There is a note on portability at the bottom of the original implementation's README. Whether you want to differ from his direction here I guess you have to decide — if you do, results won't be compatible (on BE machines, which may be irrelevant). The wrapper mentioned above is another possibility for users, but this should be documented.