Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:13026 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 31513 invoked by uid 1010); 27 Sep 2004 19:05:42 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 28401 invoked from network); 27 Sep 2004 19:04:15 -0000 Received: from unknown (HELO smtp804.mail.sc5.yahoo.com) (66.163.168.183) by pb1.pair.com with SMTP; 27 Sep 2004 19:04:15 -0000 Received: from unknown (HELO notebook.local) (toddruth@sbcglobal.net@69.105.131.76 with login) by smtp804.mail.sc5.yahoo.com with SMTP; 27 Sep 2004 19:04:14 -0000 Reply-To: truth@proposaltech.com To: Jeffrey Moss Cc: internals@lists.php.net In-Reply-To: <1081475639.2789.57.camel@notebook.local> References: <20040406192114.8125.qmail@pb1.pair.com> <40735688.1090609@benramsey.com> <20040408222823.7283.qmail@pb1.pair.com> <006001c41db9$748a4330$0a00a8c0@home.jevon.org> <4075D551.7050800@benramsey.com> <1081475639.2789.57.camel@notebook.local> Content-Type: text/plain Message-ID: <1096311853.8522.18.camel@notebook.local> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 27 Sep 2004 12:04:13 -0700 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] return NULL by reference From: truth@proposaltech.com (Todd Ruth) Unless the problems mentioned in the email I've quoted below have been fixed, be glad to be getting an error message. :) In the past it was quite painful to find all of the places where non-variables were used as references. A big thank you to whoever added the error message! Due to the lack of reproducability, I never filed a bug report for the crashes and corruptions I experienced. Do any of the experts out there know if the underlying problems have been addressed? Thanks! Todd On Thu, 2004-04-08 at 18:53, Todd Ruth wrote: > I'm not sure if it caused any of the issues either of you spoke of, > but I can report that PHP does have some pointer problems. I've > been putting off this email until I had written up something nicer, > but it's probably better to just get the word out (assuming this isn't > already known)... > > PHP has problems related to using a temporary as the source for a > reference. An obvious no-no is to write "$x =& NULL;" or > "$x =& @$y[5];". These are parse errors. On the other hand, PHP won't > complain about: > > function &f() { > $y = array(); > return @$y[5]; > } > $x =& f(); > > It even acts OK. The above code could be a mistake or it could be > a misguided attempt at optimization (believing that keeping a ref > to a temporary is better than setting $x equal to the temporary). > Maybe there was a desire to modify $y if applicable, but otherwise > be OK with modifying a temporary. In any case, if you have a large > enough system and code like that lying around, there's a good chance > you'll get crashes. You may not get a crash but instead see unrelated > data mysteriously changed in functions that get called later. > There are at least 2 ways to adjust the code above to make PHP > happy. One is to remove the "&" in the assignment. Another is > to create a "real" temporary variable instead of letting PHP make its > own temporary. ie > > function &f() { > $y = array(); > $temp = @$y[5]; > return $temp; > } > $x =& f(); > > I've had crashes go away and mysterious data overwrites go away with > the only change to the system being replacing a piece of code like > the first block of this email with a piece of code like the second > block. This has happened for just about every kind of "=& temp" you > can think of. Here are a few examples (in addition to the case above) > of using temporaries as sources for references. I think we've had a > crash / mysterious data overwrite for just about all of these (if not > all). > > function f1() { > $y = 5; > return $y; > } > $x =& f1(); // Get rid of the & or add an & to f1 > > function &f2() { > return NULL; // Get rid of & below or use "$r = NULL; return $r;" > } > $x =& f2(); > > function g() { > return NULL; > } > function h(&$x) { > $x = 5; > } > h(g()); > > That last one could use some combination of the above recommendations > to be fixed. For the record, I agree that there are few (if any) cases > where the above code is the best code for a design problem, but I also > dislike that these code blocks can lead to crashes / corruptions. > > BTW, we have never had a problem with using a temporary reference as > the source for a non-reference copy. That is to say the following has > never caused us a problem: > > function &f() { > $y = 5; > return $y; > } > $x = f(); > > Best of luck, > Todd