Analysis of the bug that the PHP error suppressor (@) causes failure to pass parameters by reference_PHP Tutorial

Look at the example below:

Copy code The code is as follows:

$array = array(1 ,2,3);
function add (&$arr) {
$arr[] = 4;
}
add(@$array);
print_r($array);
/**
At this time, $array has not changed, output:
Array
(
[0] => 1
[1] => 2
[2] => 3
)
*/
add($array);
print_r($array);
/**
Without error suppression, the output is normal:
Array
(
[0] => 1
[1] => 2
[2] => ; 3
[3] => 4
)
*/
?>

I have never encountered this problem before, so I first looked for relevant information to see if there is any ready-made answer. After searching on Google, I found that although someone has reported a similar bug to PHP: http:// bugs.php.net/bug.php?id=47623, but PHP official has not solved it yet and has not given a reply.

There is no way, I can only analyze it myself. I have introduced the principle of error suppression in the article before (In-depth understanding of PHP principles of error suppression and embedded HTML). In principle, error suppression only modifies error_reporting level, it stands to reason that it will not affect the function calling mechanism between contexts. This can only be done through field testing.

After gdb tracking, it was found that after using the wrong transplantation operator, the parameter opcode before the function call is different:

Copy the code The code is as follows:

//When the error suppressor is not used
OPCODE = SEND_REF
//After the error suppressor is used
OPCODE = SEND_VAR_NO_RE

Initial problem Positioned, but what is the reason for this difference?

Since the OPCODE is different, it must have taken different branches during the syntax analysis stage. Thinking of this level, the problem is solved Positioned,

It turns out that in the PHP syntax analysis stage, entries in the form of "@" + expr are reduced to expr_without_variable, and the meaning of this kind of node is the value without a variable, that is, a literal value. We We all know that literal values ​​cannot be passed by reference (because it is not a variable), so this difference will result.

The specific process is as follows:
1. Syntax analysis stage:

Copy code The code is as follows:

expr_without_variable:
//...with omission
| '@' { zend_do_begin_silence(&$1 TSRMLS_CC); }
expr { zend_do_end_silence(&$1 TSRMLS_CC); $$ = $3; }
//The ZEND_SEND_VAL branch is gone here
non_empty_function_call_parameter_list:
expr_without_variable { ....} // I mistakenly took this branch
| variable {..... } //Normal situation

So different OPCODEs are generated during compilation, which also leads to the appearance of problems.
Finally, I have explained the reason on this bug page of PHP. If you are interested, you can check out my poor English. Finally, thank you cici netizen for providing this interesting question.

http://www.bkjia.com/PHPjc/323224.htmlwww.bkjia.comtruehttp: //www.bkjia.com/PHPjc/323224.htmlTechArticleLook at the example below: Copy the code The code is as follows: ?php $array = array(1,2,3); function add ( } add(@$array); print_r($array); /** At this time, $array has not changed, output: Array ( [0] = 1 [1...