From: Zeev Suraski
> It's not a correct fix :I get_ptr_ptr must return the address of an > allocated zval *, one which can later be separated, > etc. T(result->u.var).var.ptr doesn't fall into that category - it can be > gone in the next opcode... > > The only safe way to return a zval ** is for the underlying object model to > implement get_ptr_ptr...
What is this then a catch 22? If get_ptr_ptr is implemented and returns an allocated zval **, then you can run into problems using pre/post_incdec if you need to rely on the read_property and write_property of those functions, which are only hit if you return NULL from get_ptr_ptr, which then brings one back full circle to getting an error in zend_fetch_property_address_inner when returning a NULL zval **.
I guess so, yes, it's a bit of a catch 22. get_ptr_ptr is used in very rare cases - assign-by-reference is one of them, and pre/post incdec is another. The assumption is that if you provide get_ptr_ptr, the engine can perform incdec on its own, without calling read_/write_property. It's basically an optimization for standard PHP objects. So if you want to support assign-by-ref and also override incdec, I guess it cannot be done right now.
The correct solution, I think, would be adding a boolean function (or even just a bit) to the handlers structure, that instructs the engine whether it should use get_ptr_ptr for incdec or not, since it's an optimization. Maybe we can just check whether we're dealing with PHP objects and perform this optimization only then. I need to look into it.
Zeev
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
