Re: Copy On Write and Assign By Reference perform different on PHP5 and PHP7

From: Date: Thu, 31 Mar 2016 17:23:32 +0000
Subject: Re: Copy On Write and Assign By Reference perform different on PHP5 and PHP7
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-92051@lists.php.net to get a copy of this message
Huqiu Liao wrote on 31/03/2016 17:47:
Hi, internals, I have a question about Assign By Reference and I posted on StackOverflow, I'd like to know the reason behind it, and I did not get any this kind of answer, can anyone give me some clues. --- We have a piece of simple code:
1    <?php
2    $i = 2;
3    $j = &$i;
4    echo (++$i) + (++$i);
On PHP5, it outputs 8, because: $i is a reference, when we increase $i by ++i, it will change the zval rather than make a copy, so line 4 will be 4 + 4 = 8. This is Assign By Reference.
To me, that sounds like a fixed bug. It's noteworthy in the 3v4l results that HHVM also gives 7 as the answer, and I can't see any logical reason for the answer to be 8 - regardless of execution order, the result of the two calls to ++$i should never be the same. It would be interesting to see the VLD dump in PHP 5, with and without reference, because looking at the PHP 7 one, it's clear that the two increments result in two temp vars so it shouldn't make any difference what type of zval was given as input:
   4     2        PRE_INC $2      !0     # !0 is compiled $i, $2 is a new value returned
         3        PRE_INC $3      !0     # !0 is referenced again, but $3 is unrelated to $2
         4        ADD ~4      $2, $3    # the two values are added, with no reference to !0
Maybe in PHP 5 the opcodes are the same, but $2 and $3 somehow end up as references to !0, rather than new zvals, as though the code were: $i = 2; $i++; $temp1 =& $i; $i++; $temp2 =& $i; echo $temp1 + $temp2; rather than, as seems logical to me, HHVM, and PHP7: $i = 2; $i++; $temp1 = $i; $i++; $temp2 = $i; echo $temp1 + $temp2; Regards, -- Rowan Collins [IMSoP]

« previous php.internals (#92051) next »