Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:49698 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 3827 invoked from network); 16 Sep 2010 09:57:03 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Sep 2010 09:57:03 -0000 Authentication-Results: pb1.pair.com smtp.mail=jb_jeff@hotmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=jb_jeff@hotmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.80 as permitted sender) X-PHP-List-Original-Sender: jb_jeff@hotmail.com X-Host-Fingerprint: 65.55.111.80 blu0-omc2-s5.blu0.hotmail.com Windows 2000 SP4, XP SP1 Received: from [65.55.111.80] ([65.55.111.80:17051] helo=blu0-omc2-s5.blu0.hotmail.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F3/88-48270-EE9E19C4 for ; Thu, 16 Sep 2010 05:57:03 -0400 Received: from BLU138-W20 ([65.55.111.73]) by blu0-omc2-s5.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Sep 2010 02:57:00 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_ba798480-649b-4033-aeaa-098bf8060a29_" X-Originating-IP: [84.108.22.110] To: Date: Thu, 16 Sep 2010 09:56:59 +0000 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 16 Sep 2010 09:57:00.0270 (UTC) FILETIME=[818CF0E0:01CB5585] Subject: Understanding the benefits of handling Bucket data in PHP's HashTables From: jb_jeff@hotmail.com (Jeff Brown) --_ba798480-649b-4033-aeaa-098bf8060a29_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hey guys (and girls)=2C I have been reading this list for sometimebut this is the first time I'm ac= tually posting something.This might fit better in a C\C++ forum but I base = my question on the notion that I confidence in my C skills and that there i= s an underlying cause for the choice of PHP developers to save Bucket data = 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=2Cze= nd_hash_add) and I saw that zend_hash_add (macro for _zend_hash_add_or_upda= te) accepts pData as void * but is usually passed an address of a pointer l= ike in: zend_class_entry *ce=3Bzend_hash_add(CG(class_table)=2C "class_name"=2Cclas= s_length+1=2C &ce)=3B pData is in turn memcpy'd into a Bucket's pData element which is also void = *=2C passing the &ce suggests that what will get memcpy'd will be the conte= nts of &ce which is in turn the address pointed to by ce=2C the address of = a zend_class_entry struct=2C this suggests that the Bucket's pData element = though marked as void * actually servs as a void ** (since it points to an = 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 zend_= 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 c= lass_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 in = pData itself which is &ce=2C this sets ce to point to an address of Bucket-= >pData which as I established earlier is used as a void **. I may be missing some basic understanding in pointers but I am pretty confi= dent that this is not the case and thus I am asking is there a specific rea= son 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. = --_ba798480-649b-4033-aeaa-098bf8060a29_--