这是不是PHP的bug? - 开源中国社区
当前访客身份：游客 [
当前位置：
&$array = [ 1, 2, 3 ];
&echo implode(',', $array), &\n&;
&foreach ($array as &$value) { }
&echo implode(',', $array), &\n&;
&foreach ($array as $value) { }
&echo implode(',', $array), &\n&;
1,2,3 1,2,3 1,2,2
共有9个答案
<span class="a_vote_num" id="a_vote_num_
不是 &bug 第一个 foreach 用的是引用
也就是 在第一个foreach 执行 之后, $value 这个变量就是$array 这个数组最后一个元素的引用
当你执行第二个foreach的时候，数组的元素赋值给value的时候上就是在改变 $array这个数组的最后一个元素的值
所以实际上foreach执行时 数组的值是这么变化的
[1,2,1] & &[1,2,2] 注意当变成[1,2,2] 的时候,由于数组最后一个元素的值已经改变,所以赋值给$value 的时候, 依然为 2
所以第二个foreach执行完之后 数组实际上就已经变成了 [1,2,2] 了
<span class="a_vote_num" id="a_vote_num_
没有BUG，你的foreach循环体根本没有语句执行。
<span class="a_vote_num" id="a_vote_num_
&&&&可以说是bug，也可以说不是。不过PHP开发组表示这不是一个bug，也不会修改这个语言特性。但是这确实是一个bug，很多人都认为就是bug。
&&&&这个特性确实很容易让人困惑，这种很诡异的不符合直觉的代码可以归为bug。虽然可以用opcode来解释，不过这个属于从结果来找原因了。
--- 共有 2 条评论 ---
: 我看到的评论，主要是说PHP缺少块级作用域，会受到function-level的副作用影响。我觉得还是有道理的
(2年前)&nbsp&
其实是符合代码逻辑的。也说不上是bug。
最后一个&$value在循环之后还存在。
下面的$value就是这个对数组最后一个元素的引用。所以这样。
引用循环后，需要unset掉引用变量。至少每次循环都用不同的变量吧。
我敢打赌，c或c++的应该不会犯这个错误。因为他们使用变量都是很小心的。纯php像我这样的，就比较容易掉进去。
(2年前)&nbsp&
<span class="a_vote_num" id="a_vote_num_
你的数组定义写的不对，下面是php手册的片段：
The weird behaviour of references in foreach remains as long as in PHP 5.2.08& (Linux) and PHP 5.2.9 (Windows XP).&& The simplest example would be:
&?php &&& $a = array('a', 'b','c'); &&& foreach($a as &$row){ && & && //you don't have to do anything here && & & } &&& print_r($a); &&& foreach($a as $row){ && & & echo &&br /&&.$row; &&& } ?&
the result of print_r will be correct - array of ('a','b','c') values. The second foreach, however, would
produce a,b,b. For all arrays, regardless of size, it would be the n-1 element &(the element right before the last one). Eg. for 'a','b','c','d','e','f', the script would produce a,b,c,d,e,e.
There are few solutions to this:
1. safest - avoid using r& so instead of
&?php foreach($a as &$row){ &&& // do something, eg. &&& $row = trim($row); } ?&
you would use
&?php foreach($a as $i=&$row){ &&& // do something on row, eg. &&& $row = trim($row); &&& // replace the row in the table &&& $a[$i]=$row; } ?& decrease of performance is the cost, however
2. equally safe and more usable - unset the element reference right after the foreach loop with references, eg.: &?php &&& $a = array('a', 'b','c'); &&& foreach($a as &$row){ && & && //you don't have to do anything here && & & } && & & unset ($row)); // it is safe now to use $row again &&& print_r($a); &&& foreach($a as $row){ && & & echo &&br /&&.$row; &&& } ?&
3. use ref it seems that iterations work correct if you use &$row in both loops or don't use it in any:
&?php &&& $a = array('a', 'b','c'); &&& foreach($a as &$row){ && & && //you don't have to do anything here && & & } && & & print_r($a); && & & // works OK now even without unset($row) &&& foreach($a as &$row){ && & & echo &&br /&&.$row; &&& } ?&
4. use references in foreach only inside
outside the function scope it should be safe
&?php function cleanTable($a){ &&& foreach($a as &$row){ && & && $row = trim($row); &&& } }
$a = array('a','b','c'); cleanTable($a); foreach($a as $row){ echo &&br /&&.$row; } ?&
drawbacks: NONE! I Quite contrary, the code looks more tidy.
5. avoid using the same variable names for referenced and non- for example, in the first case use &$rRow, and in the second one - $row. It's neither elegant, nor efficient, though, as each new variable lowers the application performance a bit. &?php &&& $a = array('a', 'b','c'); &&& foreach($a as &$rRow){ // $rRow for 'referenced row' && & && //you don't have to do anything here && & & } &&& print_r($a);
&&& foreach($a as $row){ && & & echo &&br /&&.$row; &&& } ?&
--- 共有 3 条评论 ---
: 你们都好时髦，我还在5.3。。。
(2年前)&nbsp&
$arrr = [];
//这个是php5.4开始添加进来的，数组的精简语法
(2年前)&nbsp&
这个是 5.4版本以上的 array 所以是[]
(2年前)&nbsp&
<span class="a_vote_num" id="a_vote_num_
这不算bug吧
第一个foreach以后 &$value 一直指向 数组最后一个位置&
第二个foreach里 实际上是没循环一次 都把当前值赋给最后一个位置
第二个forecah里打印数组的变化就可以比较清楚了
$array = [ 1, 2, 3 ];
foreach ($array as &$value) { }
echo implode(',', $array), &\n&;
echo '---------------foreach------------------'.PHP_EOL;
foreach ($array as $value) {
&&&&echo implode(',', $array), &\n&;
echo '---------------endforeach---------------'.PHP_EOL;
echo implode(',', $array), &\n&;
<span class="a_vote_num" id="a_vote_num_
第一个foreach结束时$value变量并未销毁，并且$value此时是$array[2]的一个引用。
当第二个foreach开始时
$array[2] = $value = $array[0] = 1
此时array=[1,2,1]
接着 $array[2] = $value = $array[1] = 2
此时 array = [1,2,2]
$array[2] = $value = $array[2] = 2
结果就成这样了
<span class="a_vote_num" id="a_vote_num_
首先楼主要明白PHP一个很重要的事：全局变量和局部变量。
所谓全局变量，则一般为$_GET $_POST $_REQUEST 这些PHP自身提供的全局变量，方便给各位开发时在任何地方都可以轻松调用。（试想，在a.php中检查$_GET中的某个值是否合适，然后请求b.php里的方法，在该方法里再次检测$_GET这个值是否合适——这个过程需要传递参数吗？不用）
也可以使用global关键字声明全局变量。例如任何地方 global $global_val = &我是全局变量，你在任何地方都可以echo到我！我的存在是为了方便你在这次生命周期中拥有我&;
局部变量是指在函数块内部的变量，例如function me(){$var1 = &我是局部变量，在这个函数之外你echo不出我&;}
<span class="a_vote_num" id="a_vote_num_
foreach里多了一个&
<span class="a_vote_num" id="a_vote_num_
这些东西还是你自己理解了原理在说这些话！
更多开发者职位上
有什么技术问题吗？
PHP仁波...的其它问题
类似的话题为什么不存在没有bug的程序？ | 问答 | 问答 | 果壳网 科技有意思
为什么不存在没有bug的程序？
不管怎样debug都不可能把所有的错误挑出来吗？
+ 加入我的果篮
计算机软件专业，科幻迷
It's not a bug, it's a feature。
电子工程专业
Hello, world就是没有bug的程序
高中退学，独立开发者，独立博客作者，深度 Git...
因为bug是一个相对的概念，你认为是bug，但别人可能认为这是功能一个功能，今天可能算功能，明天就可能是bug
非确定有限状态自动机
呃，这个算是计算机科学最前沿的问题了吧。程序的运行过程（尤其那些有输入输出的程序）是非常复杂的，复杂程序的运行路径几乎是无穷多条，人力怎么可能证明每条路径都是正确的？一般想到都是用数学形式证明，但因为什么是bug根本无法定义，形式证明只能解决一部分问题。
我很意外这么大众的一个问题没有让我满意的答案，那我尝试说明一下：1972年图灵奖获得者,大神Edsger W. Dijkstra总结过：“Testing shows the presence, not the absence of bugs”。本质来讲有没有bug是个不可判定问题（undecidable)，所以只能发现bug，不能说“没有bug”。举个例子：if (哥德巴赫猜想成立){ 楼主比我帅 //这明显是错的！}请问这段代码有bug吗？如果哥德巴赫猜想成立，那么它有bug。天知道哥德巴赫猜想成立不？这段代码永远停滞在这里直到哥德巴赫猜想有证明结果为止。如果把条件中的哥德巴赫猜想换成一个已知是不可判定的问题，这就更无厘头了。
我觉得大概可以这么理解，越复杂的东西，越容易出错。比如说一个50%出错几率的零件，系统中只用一个零件，那么系统出错几率是50%，两个是75%，三个就是87.5%……所以随着系统复杂度的上升，bug无法避免。理论上来说，只要做了足够多的测试，测试过了所有可能的case，应该能查出所有bug来。但是实际上这个是不现实的，成本无法接受，也许99%的defect被发现，但是为了发现剩下的1%，往往会花费远比发现那99%多得多的成本，带来的收益却很有限。并且，实际工作中为了修复一个defect，导致更多defect产生的情况屡见不鲜。从风险控制的角度来说，我们不会追求消灭所有的bug，只是在软件存在bug的风险和软件成本中间找一个平衡点。撇开程序不谈，人类进化了三百万年，也还是生老病死，各种遗传性疾病屡见不鲜，还有癌症这种系统自身崩溃的重大bug。但是进化很大程度上只是尽力避免种群被灭绝的风险，这一点上显然人类足够成功，那就够了……
果壳“万有青年”品牌负责人
白天不懂夜的黑
我想，一个很重要的原因，是我们对逻辑做不到100%的把握所致。诚然，有为数不少的bug是编程语言语法，或者某种语法机制上本身存在的漏洞所致——这可以认为是语言创制者留下的bug.比如C语言里的数据类型不匹配，数组，指针越界 之类。这种bug，在强调了一定的编程规范或者使用更严格的语法检查器后，比如pc-lint，在感觉上，会让我们觉得有望根治。然而，另一种更常见的错误是 逻辑错误。让你写一个只有五六行的helloworld，你可以做到没bug；让你写一个软（件的）数据锁存器，也许你也可以做到没bug；但是如果让你写一个10K甚至50K行规模的C代码，你可以保证你所做的逻辑结构100%是正确的？我想，没人敢那样说。既然 逻辑都错了，或者有漏洞，还有谁敢说，这样的程序是无bug；
关于helloword 有木有bug 首先定义一bug是什么， 在我们这个鸟公司， 客户的不满就是bug。在这个前提下我们推出了一个win8版本的helloword， 为了让界面更骚，我们用了metro， 然后兴致勃勃发给客户，客户收到以后充满基情的安装 发现无法运行， 哦 shit ， 客户竟然还在使用win98， 尼玛啊， 这难道是win8的舅舅么？ 好吧这时候前端技术实施电话过来吼了， 你们这帮熊孩子，搞这么严重的bug。 你看看bug无处不在，时时刻刻就会出现。 并且总是在基情高潮的时候到来， 像不像月经？
“苹果”富可敌国 乔布斯创新不止
不是，有的程序就没有bug，比如不让你进行任何操作的程序
程序猿 代码格式化洁癖 理想主义洁癖 等
debug只能解决代码的错误.但是很多错误是业务方面的错误.也有人自身思维的错误.比方说人工智能....
其实hello world也是可以有bug的。。。若是处理器来了个微妙的bug。。哈哈还别说，真有这事。google一下，你就知道
好歹当码农有段时间了, 没学过高深理论,我试着回答一下,从逻辑上讲, 没有什么理论思想在任何条件任何认识下,都一定正确 不是吗? 我觉得没有, 通俗的说1+1一定等于2吗, 看是什么人回答了. 既然思维逻辑上存在不确定性, 那么, 程序逻辑上可能有Bug很正常, 程序仅是思维的表现么.从实现上讲, 你无论你写多么简单的东西, 都要依赖外部现有的东西, 外部实现的可靠性就没有绝对的100%, 你的程序就不可能有100%的可靠性. 例如, 就算是最简单的在printf Hello World也要用到系统复杂的输入输出系统. 较真的你可能会说你要用汇编, 实现最简单的程序, 但你一样会依赖CPU的解释程序, 即使它们绝对没有问题, 硬件也没有100%的可靠性, 它们只是在常温室内等条件下 比较可靠而已.之所以没看到Bug, 仅是你没开启触发Bug的条件而已, 程序猿与Bug的命运是注定的哈.以上, 轻喷.
/* i have no bug. */
勘查技术与工程专业，编程爱好者
#include &stdio.h&int main(){
printf("This is a program which have no bug.\n");
return 0;}
电子农场的游牧民
个人认为BUG问题和数学猜想是一样的，没有前题说BUG没有意义。大众点的例子就是：一个程序，其他情况不变，一个人用没有问题，一百个同时人用，一千个人同时用就不一定没问题。硬件之间的不同也会引发问题，有的可能莫名奇妙。
其实我感觉是这样的
程序往最底层延伸的时候其实都是调用的算法包括操作系统提供的接口 函数等都是由算法组成的
当各种算法结合以后 程序就不那么严谨了
所以没有不存在BUG的程序 只有没发现BUG的程序
传说中的战士
我们做了一个1.5MB的系统，和Windows一样的，就没有BUG……
只能判断一个东西“有”，而不能判断一个东西“没有”
停机问题就是bug的祖宗吧，所以任他什么程序，永远有大于等于一个bug。
理学学士；PG；脑门控；EVA控；科幻
就算一个小程序，调试修改成0个BUG的状态，后面还有成百上千条waring跟着呢
这个问题本身就是有问题
没有给出bug的定义
度娘的贴吧个有起源第一代的计算机是由许多庞大且昂贵的真空管组成，并利用大量的电力来使真空管发光。可能正是由于计算机运行产生的光和热，引得一只小虫子（Bug）钻进了一支真空管内，导致整个计算机无法正常工作。如果把bug定义为可能无法实现程序本身的目的
那么没有bug的程序不存在
hollo world？没有bug？java是高级语言
我理解为媒介
计算机只能看懂10看不懂hollo world
把电脑上的java卸了那hollo world也变成了bug
因为无法在屏幕上打印
违背了初衷
或者更干脆
把显示器砸了
那么程序都有bug这句话就不仅限于计算机程序
拿最简单的膝跳反射
反射弧的5个部分哪个部分钻进了“bug”都会影响结果
没有限定条件拿句口号来空谈会被骂死的→_→
顺便吐槽楼上的1 1等于2
在《1984》条件下它不成立谢谢
是你无法证明一个程序没有bug，而不是不存在。
不一定，比如printf("你好~");
只能数到三......
程序渣渣员
这是个哲学上的问题，今天刚考完马原的人面无表情的说……
我觉得是没有完美的程序，永远都有改进的可能。即使是hello world！
只要人会出错，BUG就会一直存在。谁让程序是人写的呢！
一个标准的程序应该有输入和输出吧？ 那么在这两个过程中很难保证在任何情况下都不会出错。所以还是会有小虫子的
把这句话的深度推到"不能自证",有点深了,貌似我们周围所有的逻辑系统都不能自证.我觉得这句话可以这么理解,"不存在没有bug的有需求的程序",无需求的程序自然是没有bug的,有需求的程序一定会有bug.比如hello,world.他的本身你当然没办法说对错,但是当你界定了需求,那就有了.如果你把它当成一个教材类的演示用程序,那有些人可能通过这个程序并不能理解C语言(假设这个程序使用C语言写的)的基本输出方式,你甚至可以找出n个理由说明这个例子不适合用于教学.如果你把他当成一个测试程序,测试一个机器能不能跑(X86构架下的程序),一台苹果机也有很小的几率通过测试,那他也不是一个完美的测试程序.
杂牌工程师
这个不是技术问题，个人认为程序是人类解决问题方法的抽象总结，只要是人的想法，就有不足和漏洞，这个取决于解决问题的角度和环境谁说helloworld没有bug的，内存不够怎么办，有做处理了吗。但凡需求要求输出Helloworld，你搞成了helloworld，这也是Bug
想起了一哥们的名言：我的程序没BUG，如果有，那一定是微软的 :D
简单就没有bug
现在的程序bug一般不是出现在算法上，编译也不会有问题，问题是在流程上，是设计缺陷，这叫bug。有bug不是运行不了，而是运行错误、运行了非程序设计者预想的路径、得到了非预期的结果，不是debug就可以的
哥德尔不完备。
debug只能证明程序没有错，却不能证明程序是正确的。 ——谁说的我忘了
c++码农，自学web中...
并非不能完全消灭bug，前提是需求不变，测试时间充足，但实际上为了迎合市场，产品经理或领导，程序经常会改变，改变就会有新的bug产生。另外一个原因是程序的规模不断变大，在30年前的程序，1万行以内的程序比比皆是，但如今，需求越来越复杂，程序为了满足各种需求 ，自然代码行数提高，举个例子，具体到某些软件，如果需求增加N个，且这些需求之间，或与旧的需求是有相互关系的，那么复杂度不是以线性增加的，而是以指数级别增加的。 程序员难以hold住这么多细节，只能以测试辅助找出bug，但难免会有漏网之鱼。总体来说，现在的软件方法论只是降低bug发生的概率，但面对现在对软件各种奇葩需求的修改，软件方法论也hold不住啊。
看要实现什么机制，有的时候在实现多重机制的情况下，逻辑代码按照你的思维去运作，但在其他环境下，其他情况下，你所编写出的代码将会不可避免的出现纰漏，因为你没有想到复杂环境下的程序状态，尤其是多重机制。这个BUG是永远都解决不完的，你这样修改在你可视的环境中他运行的很好，但换种情况换种环境，问题就会出现，那些看起来没有BUG的程序其实是在已知环境下控制漏洞到最小，但不能完全消灭。人类本身就有BUG，何况所产生的思维以及代码。
邪恶之王 大毒舌 欢乐
jmp f000 fff0
被电脑玩的
想想无限不循环小数，你越算，近似程度越高，但还是无法结束。
菜鸟程序员
我觉得也是相对而言的。我程序里有个死循环，这是不是bug？
bug都是相对的！
就算程序本身没错，遇上奇葩的使用者照样会出问题...（有多少人会看软件的说明书来着？）
笨蛋|逗逗逗|
人无完人。
我觉得因为程序没有完美的思维，是死的，不能如生物般完美，必然有bug。非生命体
谁告诉你 程序就一定有BUG了 像一些简单的程序就没有BUG 即便是复杂的 也可能没有BUG 比如火箭 宇宙飞船 高铁 那可是关系到生命的
后回答问题，你也可以用以下帐号直接登录
(C)2016果壳网&&&&京ICP证100430号&&&&京网文[-239号&&&&新出发京零字东150005号&&&&
违法和不良信息举报邮箱：&&&&举报电话：是不是所有的bug软件缺陷都需要修复？_缺陷管理_领测软件测试网
是不是所有的bug软件缺陷都需要修复？
发表于：来源：作者：点击数：
近来我遇到越来越多的人对我们会发布还有 bug 的产品大为惊讶。而让我大吃一惊的是，这些人中还有许多是软件 测试 人员，我本以为他们应该对此早已经有所了解。建议大家先阅读Eric Sink较早写的（但是很棒的）文章。不知道我还能对此话题有多少贡献，但我想
近来我遇到越来越多的人对我们会发布还有的产品大为惊讶。而让我大吃一惊的是，这些人中还有许多是软件人员，我本以为他们应该对此早已经有所了解。建议大家先阅读Eric Sink较早写的（但是很棒的）文章。不知道我还能对此话题有多少贡献，但我想试试。许多bug并不值得去修复。“你这也算是吗？”，你肯定会冲我大叫，“测试人员是产品的捍卫者。”我可以再重复一次（如果需要的话）许多bug并不值得去修复。“让我来告诉你原因。在大多数情况下，修复bug就必须要修改代码。而修改代码需要投入资源（时间）并会引入风险。这真是很糟糕，但这却是事实。有时，如果风险和投入远超过修复bug的价值，因此我们就不会被修复这些bug。我们决定是否修复一个bug并不是，也不应该是靠“感觉”。我喜欢用“用户痛苦”的概念来帮助我做决定。我会用三个关键因素来考虑并确定“用户痛苦”：1、严重性&—— 这个bug将产生什么影响 —— 它会让整个程序崩溃吗？它会导致用户的信息丢失吗？或者并不是那么严重？有更简单的解决方法吗？还是它仅仅是个无关紧要的问题？2、频繁性&—— 用户碰到这个问题的频率高吗？它是程序主要工作流程中的一部分？还是隐藏在一个并不常用的功能中？在最常用的那部分程序中存在的小问题很可能是需要修复的，而一些不常用到的那部分程序中存在的大问题，也许我们会放在一边。3、对客户的影响&——如果你之前准备工作做得好，你应该已经知道你的客户是谁，你的每个客户群中会有多少（或者是你希望有多少）用户。这样你就需要判断，这个问题将会影响到每位用户一，还是仅仅一部分人。如果你能追踪出客户如何使用你的产品，你就能得到更准确的数据。以上3点因素就构成了一个公式。给上面的每一个因素都分配一个数值范围，并且用一些计算 —— 你可以直接使用加法、乘法或是基于你的应用程序以及市场因素加上权值。打个比方，我们只需要执行加法并且对每个bug赋予10分的数值范围。Bug #1：比如它是一个会让程序崩溃的bug（10分），它存在于程序的主要部分（10分），它影响了80%的客户（8分），因此这个bug的”用户痛苦“量值为28分，我们打赌我们肯定会修复它。Bug #2：它仅仅是一个关于排列的bug（2分），它出现在二级窗口中（2分），这个bug所在的那部分程序只会在旧版本中被使用到（2分）。因此这个bug的“用户痛苦” 量值为6分，我们很可能不会去修复它了。遗憾的是，很多情况并不像上面所说的那么简单。Bug #3是一个数据丢失问题（10分），它存在于一个应用程序的某个主要部分中，却只在某些特定的情况下才出错（5分）（顺便提一下，数据是主观编造出的）。客户研究证明它很少会被使用（2分）。因此它的 “用户痛苦”量值为17分，这是一个模棱两可的数据，修与不修都可以。一方面，修复它所需要的投入可能并不值得，只要这个问题能够被理解，并且它没有任何盲点，不再理会这个bug很可能是正确的处理方法。从另一方面来看，你必须把它和系统中的其他bug进行权衡。我们在这里应用“破窗效应（Broken Window）”—— 如果应用程序中有太多此类中等阈值的bug，产品的质量（或者最起码，从质量的感觉上）一定大受影响。你在考虑系统中每一个bug的时候，还应该结合考虑系统中其他（已知的）bug，并且以此来分析、决定哪些bug是需要被修复的而哪些则不值得被修复。正式发布的软件中有bug的确是一件十分糟糕的事 —— 但基于我们现有的工具和，我们还没有找到一个更加合理的解决方法。补充：补充：写出这篇文章的时候，我想我遗漏了公式中的第四个因素：发布日期。临近发布日期时，这个因素在修复/不修复bug的决定中也起了关键作用。然而我并不确定它是否是第四个因素，也无法确定在临近发布时期时，修复一个bug所需要的 “用户痛苦”量值的阈值是多少。
原文转自：
评论列表（网友评论仅供网友表达个人看法，并不表明本站同意其观点或证实其描述）是不是有bug大神告诉我打了10万场表示没见过
Copyright@ Tencent. All Rights Reserved
腾讯公司 版权所有}