Thanks to michaels (at) crye-leike.com for the followup. He produced a
much shorter version of the code that produces the same result:
<?php
class Foo {
function &getThis() {
return( $this );
}
function destroyThis() {
$baz =& $this->getThis();
}
}
$bar = new Foo();
$bar->destroyThis();
var_dump($bar);
?>
Interestingly if you change the return( $this ) in &getThis() to return
$this; the bug is reproduced. Weird, parentheses making the difference.
I had thought it was related to the depth of subclasses and the particular
arrangement of members; i.e. classic buffer overrun symptoms.
So I stand corrected.
As a followup question, if I have a large body of code for which I cannot
produce a small test case what's the recommended approach to tracking it
down .. pass it by here before posting the bug report? I've still got that
weird PHP 4.3.10 bug that should also get resolved.
DTLink Software http://www.dtlink.com
Desktop Software and Web Applications
Hi Jermo,
Are you getting an error message if you set E_STRICT?
Actually this code is not supposed to work in the first place. The reason
is that you are only allowed to return variables by reference (like in many
other languages). There was a bug in PHP 4 and early versions of PHP 5
which allowed you to get around this. In PHP, if you put parentheses around
variables like you did, that becomes a read-only expression, very much like
(2+2). There is really no way of resolving that behavior. We are supposed
to print a warning or strict message when this happens but I can't check it
right now.
What is the behavior you are getting?
Andi
At 09:01 PM 3/5/2005 -0500, Yermo Lamers wrote:
Thanks to michaels (at) crye-leike.com for the followup. He produced a
much shorter version of the code that produces the same result:<?php
class Foo {
function &getThis() {
return( $this );
}
function destroyThis() {
$baz =& $this->getThis();
}
}
$bar = new Foo();
$bar->destroyThis();
var_dump($bar);
?>Interestingly if you change the return( $this ) in &getThis() to return
$this; the bug is reproduced. Weird, parentheses making the difference.I had thought it was related to the depth of subclasses and the particular
arrangement of members; i.e. classic buffer overrun symptoms.So I stand corrected.
As a followup question, if I have a large body of code for which I cannot
produce a small test case what's the recommended approach to tracking it
down .. pass it by here before posting the bug report? I've still got that
weird PHP 4.3.10 bug that should also get resolved.
DTLink Software http://www.dtlink.com
Desktop Software and Web Applications
Andi,
Are you getting an error message if you set E_STRICT?
I always run E_ALL. I've noticed that warnings and error messages are
quite sporadic. Upgrade a minor revision and code that worked before
suddenly fails with errors.
Actually this code is not supposed to work in the first place. The reason
is that you are only allowed to return variables by reference (like in
many other languages).
So in PHP return( something ) is actually doing a
return eval_expression_and_return_result;
??
that would explain a great many things.
There was a bug in PHP 4 and early versions of PHP 5
which allowed you to get around this.
Explains why it's been working for years.
In PHP, if you put parentheses
around variables like you did, that becomes a read-only expression,
very much like (2+2).
oops. what we have here is a conceptual fault on my part.
There is really no way of resolving that behavior. We are supposed
to print a warning or strict message when this happens but I can't check
it right now.
What is the behavior you are getting?
It's basically not returning the object. But given this information that
would make perfect sense.
There are no warnings about the parentheses generated; just warnings about
the returned object not being an object.
See
http://www.formvista.com/index.html?article_id=4
for a complete list of the error messages returned by the original script.
The new more concise script produces no warnings or errors of any kind and
just returns NULL
or the object depending on whether or not you include
the parentheses.
Hmm. I just checked the return() page .. and noticed the NOTE: on the
page. I don't remember how long it's been since I've looked at that but
it's clearly there.
So the bug reduces down to a lack of warning on that construct.
This may also explain the PHP 4.3.10 bug that I reported. I use return( ..
) everywhere ...
Ok. That gives me the answer I need.
THANK YOU!
Looks like I have alot of editing to do ... :(
-- Yermo
P.S. (Of course PHP shouldn't trash it's symbol table, segfault, etc ....)
Andi
At 09:01 PM 3/5/2005 -0500, Yermo Lamers wrote:
Thanks to michaels (at) crye-leike.com for the followup. He produced a
much shorter version of the code that produces the same result:<?php
class Foo {
function &getThis() {
return( $this );
}
function destroyThis() {
$baz =& $this->getThis();
}
}
$bar = new Foo();
$bar->destroyThis();
var_dump($bar);
?>Interestingly if you change the return( $this ) in &getThis() to return
$this; the bug is reproduced. Weird, parentheses making the difference.I had thought it was related to the depth of subclasses and the
particular
arrangement of members; i.e. classic buffer overrun symptoms.So I stand corrected.
As a followup question, if I have a large body of code for which I cannot
produce a small test case what's the recommended approach to tracking it
down .. pass it by here before posting the bug report? I've still got
that
weird PHP 4.3.10 bug that should also get resolved.
DTLink Software http://www.dtlink.com
Desktop Software and Web Applications--
DTLink Software http://www.dtlink.com
Desktop Software and Web Applications