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.
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().
Something unrelated: I am going to be in linköping from tomorrow until saturday next week. Anyone up for a mini pike meetup?
Arne
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
Hi Henrik,
would tomorrow around 3 work? At least tobi and me could come by at the Roxen office. I hope that some other people could also be there.
We have spent some time this week on the arm32 machine code support. There is a couple of related things we would like to talk about.
Arne
On 07/02/16 11:30, Henrik Grubbstr�m (Lysator) @ Pike (-) developers forum wrote:
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
Hi Henrik,
Hi Arne.
would tomorrow around 3 work? At least tobi and me could come by at the Roxen office. I hope that some other people could also be there.
Sure.
We have spent some time this week on the arm32 machine code support. There is a couple of related things we would like to talk about.
Ok.
/grubba
pike-devel@lists.lysator.liu.se
-
Arne Goedeke -
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum