Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:42307
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.94.56 as permitted sender)
Date: Wed, 17 Dec 2008 22:19:11 +0100
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <28434894.20081217221911@marcus-boerger.de>
To: "Etienne Kneuss" <webmaster@colder.ch>
CC: "Lars Strojny" <lars@strojny.net>, 
	"Guilherme Blanco" <guilhermeblanco@gmail.com>, 
	"internals Mailing List" <internals@lists.php.net>
In-Reply-To: <e666c3890812171059k98d98f6qfed392b19d54ac2d@mail.gmail.com>
References: <bcb7aa500812170931h218ca201j33dfb1bb3dec79de@mail.gmail.com> <1229538590.4955.15.camel@localhost> <e666c3890812171059k98d98f6qfed392b19d54ac2d@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] New function proposal: spl_object_id
From: helly@php.net (Marcus Boerger)

Hello Etienne,

Wednesday, December 17, 2008, 7:59:01 PM, you wrote:

> Hello,

> On Wed, Dec 17, 2008 at 7:29 PM, Lars Strojny <lars@strojny.net> wrote:
>> Hi Guilherme,
>>
>> thanks for moving the discussion to the list.
>>
>> Am Mittwoch, den 17.12.2008, 15:31 -0200 schrieb Guilherme Blanco:
>> [...]
>>> It seems that Marcus controls the commit access to SPL. So I'm turning
>>> the conversation async, since I cannot find him online at IRC.
>>> So, can anyone review the patch, comment it and commit if approved?
>>
>> Just for clarification, it is not about access, but about maintenance.
>> So if Marcus gives his go, we can happily apply the patch and add a few
>> tests (something you could start preparing now).
>>
>> cu, Lars
>>

> Last time I checked with Marcus, there were concerns about disclosing
> a valid pointer to the user.
> I'd be happy to see a use-case where this information is really needed
> heavily. The only real usecase of heavy usages seems to be to
> implement sets of objects. but splObjectStorage is here for that
> precise use-case...

Correct in all Etienne. The patch might be a tiny bit faster but exposes
valid pointers which is extremely bad and also allows other bad things.
That was the only reason I used md5 hashin. What I needed was something
that is really unique per object (object pointer or id plus pointer to
handler table). Since spl_object_hash() does not say how it creates the
hash it should be fine change the way it does it. Since in a new session
the hashes are of no more use we can even do that in any new version.
However I must still insist on not exposing any valid information.

Last but not least. In your code you know the maximum length of the
extression, so you can allocate the string and snprintf into it. Even
faster is to do a hexdump into a preallocated string. For the size use:
char* hash = (char*)safe_emalloc(sizeof(void*), 2, 1);
Now the dump of the two pointers.
This approach should make it a bit faster for you. Something that might
work is to create a random 128 bit hash key that is xored onto the hash
created from the two pointers. This hash key can be allocated for each
session the first time the function will be used. If you do that I am more
than happy to accept that as a replacement for current spl_object_hash().

marcus

> Regards


> -- 
> Etienne Kneuss
> http://www.colder.ch

> Men never do evil so completely and cheerfully as
> when they do it from a religious conviction.
> -- Pascal




Best regards,
 Marcus