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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
