PHP 5.0.3 losing $this - followup.

I'll go through your email later but note that E_STRICT is not part of
E_ALL. Please run E_ALL|E_STRICT

Interestingly enough, although E_ALL|E_STRICT generates the correct
return() error message in the test case, it does /NOT/ generate any such
error messages when running the full body of my project.

Just alot of "var: Deprecated." and "Assigning the return value of new by
reference is deprecated" messages.

Just an FYI.

-- Yermo

Thanks.

At 09:35 PM 3/5/2005 -0500, Yermo Lamers wrote:

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

---

---

DTLink Software http://www.dtlink.com
Desktop Software and Web Applications

---

DTLink Software http://www.dtlink.com
Desktop Software and Web Applications