Yep correct. We always prefer to also check p->h so that we minimize
the chances for reaching the memcmp()...
At 04:33 PM 1/29/2006, Sara Golemon wrote:
I wonder If I am completely missing the point, but the following piece
of code seems fishy to me:
ZEND_API int zend_hash_del_key_or_index(Has
Hello Sara,
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 del
> 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
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
JW>>/* rearranged */
JW>>if ((p->h == h) && (p->nKeyLength == nKeyLength)
JW>>&& ((nKeyLength == 0) || (!memcmp(p->arKey, arKey,
nKeyLength
This doesn't seem to be good - there's still a case when p->nKeyLength !=
nKeyLength but the match should happen - when p is 15 (int
