Re: extended objects with read_property and get_property_ptr_ptr

At 22:27 07/07/2004, Rob Richards wrote:

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