Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:21735
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <000e01c625bf$dbffe640$c21a1a44@stumpy>
To: "Stefan Esser" <sesser@php.net>
Cc: <internals@lists.php.net>
References: <43DD2D20.5010001@php.net> <000c01c62534$d48aef80$7d051fac@stumpy> <43DDD78E.7080403@php.net>
Date: Mon, 30 Jan 2006 09:08:50 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: zend_hash.c fishy code
From: pollita@php.net ("Sara Golemon")

> you are missing my point. My point is that when a hashtable contains
> these two elements
>
> example:
>
> BUCKET_ENTRY for h=15
> --- Bucket1 : key == numeric -> h= numeric hash value == 15
>     \-------- Bucket2: key == some string key, with a hash value equal
> to 15
>
> Lets assume we want to delete the key 
> "THI_HASH_A_HASH_FUNCTION_VALUE_OF_15"
> then the code in question will first hash it and gets h==15. The next
> thing it will do is go through the linked list of buckets for h==15.
> Unfortunately the check there is broken. It will first check, that p->h
> is == 15 and then check if p->nKeyLength==0 which obviously
> is for our Bucket1. Unfortunately this is already enough to evaluate to
> true. But it is not what we intended. We wanted to delete bucket2.
> But we end up with Bucket1 deleted.
>
Ah, yes, well, when you put it that way.  I can absolutely see that taking 
place.  What's worse, since DJBX33A isn't collision resistant (just 
collision avoidant) it'd be possible (in theory) to deliberately clobber a 
record by taking advantage of this (though not trivial).

-Sara