Andi Gutmans <[EMAIL PROTECTED]> 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
