快捷導(dǎo)航

PHP錯(cuò)誤抑制符(@)導(dǎo)致引用傳參失敗Bug的分析

更新時(shí)間：2011年05月02日 14:08:56 作者：

今天cici網(wǎng)友發(fā)來一個(gè)問題, 說是在函數(shù)調(diào)用參數(shù)前面使用錯(cuò)誤抑制符號(@)的時(shí)候, 貌似引用傳參就失效了. 他想讓我?guī)退獯馂槭裁?

看下面的例子:

 
<?php 
$array = array(1,2,3); 
function add (&$arr) { 
$arr[] = 4; 
} 
add(@$array); 
print_r($array); 
/** 
此時(shí), $array沒有改變,　輸出: 
Array 
( 
[0] => 1 
[1] => 2 
[2] => 3 
) 
*/ 
add($array); 
print_r($array); 
/** 
不使用錯(cuò)誤抑制的情況下, 輸出正常: 
Array 
( 
[0] => 1 
[1] => 2 
[2] => 3 
[3] => 4 
) 
*/ 
?> 

這個(gè)問題, 我之前沒有遇到過, 所以首先去找找相關(guān)資料, 看看有沒有現(xiàn)成的答案, Goolge了一番, 發(fā)現(xiàn)雖然有人已經(jīng)向PHP報(bào)了類似的Bug:http://bugs.php.net/bug.php?id=47623, 但PHP官方還沒有解決, 也沒有給出答復(fù).

沒辦法, 只能自己分析了, 之前我曾經(jīng)在文章中介紹過錯(cuò)誤抑制符的原理( 深入理解PHP原理之錯(cuò)誤抑制與內(nèi)嵌HTML), 從原理上來說, 錯(cuò)誤抑制只是修改了error_reporting的level, 按理來說不會影響到上下文之間的函數(shù)調(diào)用的機(jī)制. 只能通過實(shí)地試驗(yàn)了.

經(jīng)過gdb跟蹤, 發(fā)現(xiàn)在使用了錯(cuò)誤移植符以后, 函數(shù)調(diào)用前的傳參opcode不同:

復(fù)制代碼代碼如下:

 
//沒有使用錯(cuò)誤抑制符的時(shí)候 
OPCODE = SEND_REF 
//使用了錯(cuò)誤抑制符號以后 
OPCODE = SEND_VAR_NO_RE 

問題初步定位了, 但是造成這種差異的原因又是什么呢?

既然OPCODE不同, 那么肯定是在語法分析的階段, 走了不同的分支了, 想到這一層, 問題也就好定位了,

原來, PHP語法分析階段, 把形如 “@”+expr的條目, 規(guī)約成了expr_without_variable, 而這種節(jié)點(diǎn)的意義就是沒有變量的值, 也就是字面值, 我們都知道字面值是不能傳遞引用的(因?yàn)樗皇亲兞?, 所以, 就會導(dǎo)致這種差異.

具體過程如下:
1. 語法分析階段:

復(fù)制代碼代碼如下:

 
expr_without_variable: 
//...有省略 
| '@' { zend_do_begin_silence(&$1 TSRMLS_CC); } 
expr { zend_do_end_silence(&$1 TSRMLS_CC); $$ = $3; } 
//此處走了ZEND_SEND_VAL分支 
non_empty_function_call_parameter_list: 
expr_without_variable { ....} //錯(cuò)誤的走了這個(gè)分支 
| variable {..... } //正常情況 

所以導(dǎo)致在編譯期間, 生成了不同的OPCODE, 也導(dǎo)致了問題的表象.
最后, 我已經(jīng)把原因在PHP的這個(gè)bug頁做了說明, 有興趣的可以去看看我的爛英語水平. 最后謝謝cici網(wǎng)友提供的這個(gè)有趣的問題.

您可能感興趣的文章: