Christoph Otto wrote:
I'd appreciate comments or a quick code review as to whether I should
apply the patch as-is (sans randomization) once the failing OrderedHash
test passes. It's admittedly not a complete solution, but it does hide
Parrot's hash seed from any PARROT_EXPORT functions and
Christoph Otto wrote:
Nicholas Clark wrote:
On Sun, Nov 16, 2008 at 06:52:08PM -0800, chromatic wrote:
I'd rather remove the hash seed from the key calculation. Instead,
let's use a global seed (#defined somewhere) as the initial seed,
cache the calculated
You don't want a constant
On Sun, Nov 16, 2008 at 06:52:08PM -0800, chromatic wrote:
I'd rather remove the hash seed from the key calculation. Instead, let's use
a global seed (#defined somewhere) as the initial seed, cache the calculated
You don't want a constant global seed, else you fall foul of Algorithmic
Nicholas Clark wrote:
On Sun, Nov 16, 2008 at 06:52:08PM -0800, chromatic wrote:
I'd rather remove the hash seed from the key calculation. Instead, let's use
a global seed (#defined somewhere) as the initial seed, cache the calculated
You don't want a constant global seed, else you fall
On Saturday 11 October 2008 14:53:53 Christoph Otto wrote:
Calling string_hash with a seed value other than the one used in src/hash.c
(3793) can cause strange and wonderful failures if the STRING is reused by
imcc.
What happens is that after the STRING's hash is computed, it's cached in
# New Ticket Created by Christoph Otto
# Please include the string: [perl #59810]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=59810
Calling string_hash with a seed value other than the one used in src/hash.c
