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 >>---------------------------------------------------------------------------- >> >>-- >>PHP Internals - PHP Runtime Development Mailing List >>To unsubscribe, visit: http://www.php.net/unsub.php > > ---------------------------------------------------------------------------- DTLink Software http://www.dtlink.com Desktop Software and Web Applications ---------------------------------------------------------------------------- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
