bo...@apache.org wrote:
Author: bojan
Date: Sat Jan 28 15:54:22 2012
New Revision: 1237078
URL: http://svn.apache.org/viewvc?rev=1237078view=rev
Log:
Further improve hash randomisation:
Fix naming of a static function.
Randomise final hash produced by any hash function, using default
--- Original message ---
From: Ruediger Pluem
Don't we have the same issue here as with the XOR version of the patch?
If two different keys (key1, key2) result in the same hash value (so
ht-hash_func(key1, klen1) == ht-hash_func(key2,
klen2);) doesn't hashfunc_default result in the
On 29.01.2012 13:34, Ruediger Pluem wrote:
bo...@apache.org wrote:
Author: bojan
Date: Sat Jan 28 15:54:22 2012
New Revision: 1237078
URL: http://svn.apache.org/viewvc?rev=1237078view=rev
Log:
Further improve hash randomisation:
Fix naming of a static function.
Randomise final hash
--- Original message ---
From: Branko Čibej
A good, seeded cryptographic hash function would scatter the values much
better than this does.
Just to make the hash more resistant to having the same content in upper bits
(because we start from a common random seed), we could run the
On Mon, 2012-01-30 at 02:22 +1100, Bojan Smojver wrote:
we could run the hash value produced by hashing the strings through
the hash function twice
Like this.
--
Bojan
Index: tables/apr_hash.c
===
--- tables/apr_hash.c (revision
On 29.01.2012 16:34, Bojan Smojver wrote:
On Mon, 2012-01-30 at 02:22 +1100, Bojan Smojver wrote:
we could run the hash value produced by hashing the strings through
the hash function twice
This is overkill. If the current hash function isn't good enough,
running stuff through it twice isn't
On Sun, 2012-01-29 at 20:23 +0100, Branko Čibej wrote:
This is overkill.
Possibly. I'm going to run some tests to see whether I get final hashes
that have similar upper bits.
--
Bojan
On Mon, 2012-01-30 at 09:37 +1100, Bojan Smojver wrote:
I'm going to run some tests to see whether I get final hashes
that have similar upper bits.
The test reveals that many upper bits are the same without the latest
patch. With my latest patch, I get that fixed (i.e. the final hash is
On Mon, 2012-01-30 at 09:59 +1100, Bojan Smojver wrote:
With my latest patch, I get that fixed (i.e. the final hash is
perturbed a lot better).
Hmm, different problems emerge. The hash then has a tendency to produce
either all odd or even indexes (i.e. lower bits used to address
buckets).
I
On Mon, 2012-01-30 at 10:15 +1100, Bojan Smojver wrote:
I think I'll need to work on a different approach.
Reverting r1237078 is the answer. We should not be hashing the hash,
only the original strings, using the random seed.
Obviously, folks using custom hash functions will have to come up
On Tue, 2009-09-22 at 20:06 +, minf...@apache.org wrote:
URL: http://svn.apache.org/viewvc?rev=817809view=rev
Log:
The implementation of expand_array() in tables/apr_hash.c allocates
a new bucket array, without making any attempt to release the memory
allocated for the previous
11 matches
Mail list logo
