Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:10045
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <5.1.0.14.2.20040523160427.03309350@127.0.0.1>
Date: Sun, 23 May 2004 16:07:48 +0300
To: "Sara Golemon" <pollita@php.net>,internals@lists.php.net
In-Reply-To: <20040522211237.84677.qmail@pb1.pair.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [PHP-DEV] Analysis and Patch for Bug#28491
From: andi@zend.com (Andi Gutmans)
References: <20040522211237.84677.qmail@pb1.pair.com>

Hi Sara,

I am aware that if users really want to create a reference to the locally 
defined "$this" variable they can hack around it. As you noted they won't 
be able to change the real object though, i.e. EG(This) but only the local 
$this symbol table entry. As far as I'm concerned, the behavior is 
undefined and I don't want to do any run-time checks for this, as it'll 
just slow things down.
Post 5.0 we might want to change "$this" so that it isn't defined in the 
symbol table at all but will be dealt with at compile-time. This was my 
initial implementation but due to problems of reference assignments I opted 
for the current implementation. Maybe after investigating this again, I 
might find a different way of doing.
So the bottom line is, let's leave it the way it is, and remind me after 
5.0 to take another look. However, it is quite possible that I'll come up 
with the same conclusion that the current implementation is the best one.

Andi

At 02:14 PM 5/22/2004 -0700, Sara Golemon wrote:
>Currently, re-assignment of $this is handled in compile time but that won't
>stop anyone from creating a referenc of $this and changing its value.  Of
>course, any indirect changes to $this won't permanently change the object in
>the way that changing $this in PHP4 would have since the value of this isn't
>recovered from the symbol table at the end of the method nor will it effect
>property/method access since these are handled at compile time.
>
>The end result is the confusion found at http://bugs.php.net/28491
>
>There are three options:
>
>(A) Do nothing, "They shouldn't be trying that anyway!"  Obviously that
>won't stop someone from attempting it...
>
>(B) Prohibit creating references to $this.  Probably "good enough", but
>(maybe?) there's a ligitmate use for it.
>
>(C) Check the target variable against $this at execute time.  Has the
>advantage of keeping the ability to create references of $this but slows
>execution, especially when writing to object references from within another
>object instance.  Note: I didn't compare against EG(This) because the act of
>creating a reference to $this separates it from the original zval (which
>already has a refcount of greater than 1).
>
>
>Index: Zend/zend_execute.c
>===================================================================
>RCS file: /repository/ZendEngine2/zend_execute.c,v
>retrieving revision 1.645
>diff -u -r1.645 zend_execute.c
>--- Zend/zend_execute.c 18 May 2004 00:04:22 -0000      1.645
>+++ Zend/zend_execute.c 22 May 2004 20:06:55 -0000
>@@ -790,6 +790,13 @@
>                 }
>         }
>
>+       if (EG(This) && (*retval)->type == IS_OBJECT && (*retval)->is_ref &&
>(type == BP_VAR_W || type == BP_VAR_RW)) {
>+               /* Make sure the variable we're writing to is not a
>reference to $this */
>+               zval **thistmp;
>+               if (zend_hash_find(EG(active_symbol_table), "this",
>sizeof("this"), (void **) &thistmp) == SUCCESS && *retval == *thistmp) {
>+                       zend_error(E_ERROR, "Cannot re-assign a reference of
>$this");
>+               }
>+       }
>
>         if (free_tmp) {
>                 zval_dtor(varname);
>
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: http://www.php.net/unsub.php