Andi Gutmans <andi@zend.com> wrote:
> It indeed does look very hackish. Is this bug the same bug as the last
> patch of yours addressed?
Not the same, but those are similar in the point that both are basically
because of the current engine's limitation in handling temporary variables.
(If my understanding is correct, they are a kind of local variables which
are allocated during compile time. Am I right? :)
In this case, the problem is that no result znode is produced after
assigning a string element to another element within a string. So first I
was trying to simply set the result node with op2, the znode to be
assigned to, but that led a bunch of memleaks if op2 is IS_VAR and derived
from a zval that represents a referenced string element because that kind
of temporary variables will never be freed unless it has oppotunity to be
assigned to a real variable znode. Then the patch ended up with my
decision to statically allocate a space for such a string in each znode
structure.
> I'll try and take a look at the bug report this week. I'm not quite sure
> this can/should be fixed. AFAIK the return value of $str[1] = '*' is the
> updated string itself and not the assigned '*'.
I'm wondering if it can be fixed in a cleaner way either, but I think the
bug should be fixed in any way, as long as we have to implement
string element access by offset for backwards compatibilities.
And actually my patch addresses another bug in ZE2 code related to this
issue. String offsets should be represented by signed integers so as to
handle a erroneous case that the offset is less than 0. ZE1 has no
problems about this.
Moriyoshi
