On Fri, 03 Sep 2010 12:37:58 +0100, Michael Wallner <m...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
