#33977 [Opn->Fbk]: Only variable references should be returned by reference is buggy

ID: 33977 Updated by: derick@php.net Reported By: kulakov74 at yandex dot ru -Status: Open +Status: Feedback Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 4.4.0 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with <?php and ends with ?>, is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. Previous Comments: ------------------------------------------------------------------------ [2005-08-03 14:24:55] kulakov74 at yandex dot ru Description: ------------ Our hosting has upgraded to 4.4.0 and we got the famous notice on returning variable reference. But after fixing my code to comply weith the notice I found it is still displayed at certain circumstances. Unfortunately, I could not isolate the code that behaves this way because of the scripts complexity so I cannot provide a simple code that reproduces it. While trying to figure out what was the reason I found that many minor changes, apparently absolutely not relating to the problem, could prevent the notice from beaing displayed, while otherwise it is displayed. It could be simple output directly before or even anywhere in the script, changing the value of the dummy variable that is returned instead of false, for ex. $oNewNode=null; //... return $oNewNode; produced the notice while $oNewNode=0; with the same code did not. Logging to a file, changing the line at which the dummy assignment is done and a lot of other changes randomly toggle the irrelevant notice off. I have a script that generates pages html and the same code works with some pages but displays the notice with others; then changing it results in the contrary thing. Finally, I found one bug-proof solution that worked everywhere: $oNewNode=&$oNewNode; return $oNewNode; but overall working around the problem in the 4.4.0 release has left a very unpleasant feeling of a buggy system. Reproduce code: --------------- This does not reproduce the problem - it's just the piece of code I worked with and I added all the lines I tried to prevent the notice. function &add($mixKey, $mixVal=array()){ //Add: either a pair $mixKey=>$mixVal, //or a node $mixKey with values $mixVal, or an array of pairs $mixKey //WORKED BUT NOT ALWAYS $oNewNode=null; $oNewNode=false; //WORKED ALMOST ALWAYS $oNewNode=0; $oNewNode=1; //array if (is_array($mixKey)){ foreach($mixKey as $n => $v) $this->add($n, $v); //WORKED NOT ALWAYS $oNewNode=0; } //string or a simple array else if (!is_array($mixVal) || key($mixVal)===0){ $this->hashValues[$mixKey]=$mixVal; //WORKED NOT ALWAYS $oNewNode=0; } //node else{ $oNewNode=&new Node($mixVal, $this->bCleanup); if (!@$this->aNodeGroups[$mixKey]){ $this->aNodeGroups[$mixKey]=array(); } $this->aNodeGroups[$mixKey][]=&$oNewNode; //THIS FOR A REASON RESULTED IN EVEN MORE NOTICES UNLIKE THE COMMON RETURN! return $oNewNode; } //NO EFFECT FOR A REASON if (!isset($oNewNode)) $oNewNode=0; //THE SOLUTION $oNewNode=&$oNewNode; return $oNewNode; } Expected result: ---------------- No notices Actual result: -------------- A few notices for some pages, none for others ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=33977&edit=1