Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:49699
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.102 as permitted sender)
Message-ID: <BLU138-W19053AB27EAE5A5AE9335E977A0@phx.gbl>
Content-Type: multipart/alternative;
	boundary="_93b3530f-1671-44cc-b40e-759f0d26649e_"
To: <internals@lists.php.net>
Date: Thu, 16 Sep 2010 10:02:23 +0000
Importance: Normal
In-Reply-To: <BLU138-W2098CBD6C9E1B5826D0FD7977A0@phx.gbl>
References: <BLU138-W2098CBD6C9E1B5826D0FD7977A0@phx.gbl>
MIME-Version: 1.0
Subject: RE: [PHP-DEV] Understanding the benefits of handling Bucket data in
 PHP's HashTables
From: jb_jeff@hotmail.com (Jeff Brown)

--_93b3530f-1671-44cc-b40e-759f0d26649e_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Sorry for the formatting=2C I'm not sure why the newlines got removed since=
 I formatted this much more nicely=2C any reason why it happened? I could r=
epost it in a more readble format

> From: jb_jeff@hotmail.com
> To: internals@lists.php.net
> Date: Thu=2C 16 Sep 2010 09:56:59 +0000
> Subject: [PHP-DEV] Understanding the benefits of handling Bucket data in =
PHP's HashTables
>=20
>=20
> Hey guys (and girls)=2C
> I have been reading this list for sometimebut this is the first time I'm =
actually posting something.This might fit better in a C\C++ forum but I bas=
e my question on the notion that I confidence in my C skills and that there=
 is an underlying cause for the choice of PHP developers to save Bucket dat=
a the way they do.If I am mistaken in posting this here please let me know.
> I came to ponder this when working with hash functions (zend_hash_find=2C=
zend_hash_add) and I saw that zend_hash_add (macro for _zend_hash_add_or_up=
date) accepts pData as void * but is usually passed an address of a pointer=
 like in:
> zend_class_entry *ce=3Bzend_hash_add(CG(class_table)=2C "class_name"=2Ccl=
ass_length+1=2C &ce)=3B
> pData is in turn memcpy'd into a Bucket's pData element which is also voi=
d *=2C passing the &ce suggests that what will get memcpy'd will be the con=
tents of &ce which is in turn the address pointed to by ce=2C the address o=
f a zend_class_entry struct=2C this suggests that the Bucket's pData elemen=
t though marked as void * actually servs as a void ** (since it points to a=
n adress which should be dereferenced as a pointer).
> I validated this by looking at zend_hash_find which accepts pData as void=
 **=2C this time pData is to hold the address for the data retrieved by zen=
d_hash_find=2C this time I noticed the function call to be :
> zend_class_entry **ce=3Bzend_hash_find(CG(class_table)=2C "class_name"=2C=
 class_length+1=2C (void **) &ce)=3B
> and the data assigned to pData is :*pData =3D Bucket->pData=3B
> By my logic by setting *pData I am setting the data held at the address i=
n pData itself which is &ce=2C this sets ce to point to an address of Bucke=
t->pData which as I established earlier is used as a void **.
> I may be missing some basic understanding in pointers but I am pretty con=
fident that this is not the case and thus I am asking is there a specific r=
eason to use this sort of 'trickery' instead of  of explicitly using void *=
=2C I fail to see the harm in Bucket->pData being a pointer to the data its=
elf and the needed casts to be done instead of the current situtaiton where=
 it points to another address.
> Thank you for any light you can shed on this.
>  		 	   		 =20
 		 	   		  =

--_93b3530f-1671-44cc-b40e-759f0d26649e_--