xxHash gives incorrect value when using AsHexString method. about data.hashfunction

[AdamLeMmon01]

Test values used: txt file named hash.txt with contents:
test

xxHash value received: 398167db5dcadc4f
xxhash value expected: 4fdcca5ddb678139
note that if I use my helper to reverse the bytes, it then provides the correct output (the output hash strings just have the bytes in reverse order the first one ends with 4f, and the second one starts with 4f, etc.)

[danwize]

I just noticed a similar thing with the jenkins one at a time. When I use https://www.pelock.com/products/hash-calculator the value for the hash of "a" is CA2E9442. When I use System.Data.HashFunction, I get 42942eca.

If I use this method I get the same results as pelock.com:

uint jenkins_one_at_a_time_hash(string key, int? length = null)
{
	uint hash, i;
	for (hash = i = 0; i < key.Length; ++i)
	{
		hash += key[(int)i];
		hash += (hash << 10);
		hash ^= (hash >> 6);
	}
	hash += (hash << 3);
	hash ^= (hash >> 11);
	hash += (hash << 15);
	return hash;
}

[mifieli]

Any update on this? We have encountered this same problem as well. As long as you keep using this method the wrong way and compare hashes with this incorrect result, you'll be fine.
But we have to mix our .NET functionality and the hashes generated by this package with the AsHexString method with PHP functionality now which will also generate xxHash hex string values, and noticed that they did not match. The PHP library gives the correct result, this one does not.
I believe it can be traced back to the usage of BitConverter.GetBytes though, which (depending on your machine'es endianness) may reverse bytes around.

[brandondahler]

This is expected behavior due to the ambiguity of what it means to convert a given hash value to a hex string. For hash values that output 8, 16, 32, or 64 bits, they usually are output as a native byte, ushort, uint, or ulong.

When converting a native integer value to a hex value, the value is generally output as a big-endian string; however, when the result is truly a byte array (regardless of size) and we convert to a hex string, the value is output in byte-order (which technically is little-endian).

The exact behavior among different hash functions when executed on a big endian machine versus little endian isn't necessarily defined; however, a vast majority of them will return the same logical native value when they return a native value, and will return the same byte array if they return a byte array.

All of that aside, I unfortunately am no longer able to maintain this library due to personal responsibilities and will be archiving it soon. I'm happy to transfer ownership to a new maintainer if someone else is interested in taking ownership of this library.