Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:49564
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain nebm.ist.utl.pt from 193.136.128.22 cause and error)
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: internals@lists.php.net
References: <81.35.47051.C61C08C4@pb1.pair.com>
 <DB.50.27233.256D08C4@pb1.pair.com>
 <AANLkTi=C+oMAjCaU0Ds=Xvvijfqi5qurj6nDqHoS5O+x@mail.gmail.com>
 <2B.21.27233.A1ED08C4@pb1.pair.com>
Date: Fri, 03 Sep 2010 20:07:02 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Organization: =?utf-8?Q?N=C3=BAcleo_de_Eng=2E_Biom=C3=A9di?=
 =?utf-8?Q?ca_do_IST?=
Message-ID: <op.vig0pxcsidpuyk@cataphract>
In-Reply-To: <2B.21.27233.A1ED08C4@pb1.pair.com>
User-Agent: Opera Mail/10.61 (Win32)
Subject: Re: [PHP-DEV] Re: remove or fix zend_object_proxies
From: glopes@nebm.ist.utl.pt ("Gustavo Lopes")

On Fri, 03 Sep 2010 12:37:58 +0100, Michael Wallner <mike@php.net> wrote:

> OBJECTS2_HOWTO--okay maybe a tiny bit out of date, but  
> nevertheless--states
> that for the get_property_ptr_ptr object handler, which is supposed to
> return zval** of the property, one can use zend_proxy_objects for
> properties not really existing as zvals.

OBJECTS2_HOWTO is indeed out of date. For instance it refers to the  
handlers get_property_zval_ptr and get_property_ptr, which don't exist  
anymore.

If I'm not mistaken, the current way to return proxy objects is to return  
NULL from get_property_ptr_ptr, forcing a fallback to read_property and  
return a proxy object from there (with refcount 0 if it's not referenced  
anywhere).

>
> This objects overload the get and set object handlers (note: not  
> __get/__set)
> to enable something along the lines:
>
> class user_class extends internal_class {
> 	function method() {
> 		$ref = &$this->internal_property;
> 		/* $ref now actually is a zend_proxy_object */
> 		$ref = 1;
> 	}
> }
>
> ... but no other object handler that add_ref, del_ref, clone_obj, get
> and set are defined, which causes everything from fatal errors to SEGVs
> on simple statements like var_dump, echo, (string)-cast etc...

Yes, I've also noticed this breakage when writing the wiki page for  
objects ( http://wiki.php.net/internals/engine/objects ).

Most from the code I've seen (I haven't actually programmed anything with  
proxy objects except for making some tests while writing that page), the  
problem is not so much the engine.

Although the Zend engine also has some parts with poor proxy objects  
supports (e.g. I don't think you can use proxy objects as array indexes,  
even if the get handler would return an int/string), the problem is mostly  
the extensions, which frequently assume the handlers exist.

The engine sometimes tries to protect against this --  
Z_OBJCE/zend_get_class_entry check if get_class_entry exists before  
calling it, for instance --, but there are a lot of extensions that  
inadequately assume some handlers exist. Even var_dump assumes  
get_class_name exists...

Those bugs should be fixed and extension writes should be aware they can  
be given proxy objects, but if you're worried about those segfaults, you  
can define dummy implementations for those handlers.

zend_parse_parameters is also broken because it does not attempt to call  
the get handler when you pass a proxy object, except if you request a  
string (and even then, it prefers the cast_object handler).

> Additionally on object destruction, at the latest on shutdown,
> (the default) zend_objects_destroy_object causes a SEGV because
> zend_proxy_objects actually are not zend_objects and don't have
> a class entry.
>

I don't see the issue here. You should define an appropriate callback. If  
they're not zend standard objects, don't use zend_objects_destroy_object  
in your zend_objects_store_put call (or NULL, which defaults to  
zend_objects_destroy_object). The store accepts anything and even has a  
clone callback specifically to make easier the cloning of non-standard  
Zend objects.

-- 
Gustavo Lopes