Hi Arne.
>The documentation of the new f_hash() claims that its return value is
>architecture independent. SipHash reads its input as a series of
>little-endian 64 integers, which means that the hash value depends on
>endianess for wide strings.
Right, I forgot about that case.
>I have at some point written byte order independent versions of siphash
>for both 16 and 32 bit strings. Those can be found in commit
>21f218e51d55d8c07aff9db0cf45e4ac83050a5e as part of the bloom filter
>branch. If nobody objects, I will merge that commit into pike 8.1 and
>integrate it with f_hash().
Please do. Please make sure that the testsuite tests are correct and
cover this case while you're at it.
>Something unrelated: I am going to be in linköping from tomorrow until
>saturday next week. Anyone up for a mini pike meetup?
I'm in town (and at the office, but a visit shouldn't be any problem).
/grubba
