Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of bojan@rexursive.com
 designates 150.101.121.179 as permitted sender)
Subject: Re: svn commit: r1237078 - /apr/apr/trunk/tables/apr_hash.c
Date: Sun, 29 Jan 2012 23:56:31 +1100
From: "Bojan Smojver" <bojan@rexursive.com>
To: rpluem@apache.org
Cc: dev@apr.apache.org
MIME-Version: 1.0
Message-ID: <8361800055.1012348591@rexursive.com>
References: <20120128155422.BCF80238890B@eris.apache.org>
 <4F253CEB.5020002@apache.org>
Content-Type: text/plain; charset=utf-8; format=flowed

------- 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 same hash value for both 
> keys since the input value to hash
> is the same?

For two keys to cause a collision, the modulo (i.e. the index) has to be 
the same, not necessarily the whole hash. So, with xor, we don't gain 
anything by using seed against the final hash (modulo will change, but in 
the same way for both hash values - the collision will move to a different 
bucket). With the hash function, as long as the hash is not completely the 
same, we will most likely get a different modulo and therefore a different 
index into the table.

Make sense?

--
Bojan