也谈低级bug引来的悲伤:你能一眼看出下面的bug所在吗?
2014-03-08 11:55
323 查看
前段时间苹果公司报出了一个iOS 7.0.6的低级bug,该bug会引起中间人攻击,出现该bug的源码如下:
相信眼尖的人一眼就能看出问题所在:第二个if语句处出现了两个goto fail; 因为if语句没有加大括号,所以,只有第一个goto是属于if的,而第二个goto则是永远都会被执行到的(注:这里不是Python是C语言,缩进不代表这个语句属于同一个语句块)。也就是说,就算是前面的if检查都失败了(err == 0),也会goto fail,关于这个低级bug的详细分析请看大牛陈皓写的文章“由苹果的低级Bug想到的编程思考”,很值得一读。
话虽这样讲,但哪个程序员的生命中没出现过几个低级bug呢?这些bug真是折磨的我们痛苦不已,但同时也加深了与code的感情。
比如昨天,作为一个还算细心的程序媛(@程序媛敏敏)也被一个低级bug摧残的连自己的节日都没好好过
。
看下面的code,你说说会输出多少个“Alexia”呢?
哎,咋一眼都觉得输出256个“Alexia”,当然事实并非如此。
注意这里symbol_t为unsigned char类型,也就是symbol_t类型的变量c取值范围为0 - 255,当超过255就溢出了,不会变成256而是截断最高位重新变回0,即c=255后当c++时就变成0了,所以c永远小于CSIZE,这个循环也就永远不能结束,过不了好久程序就崩溃了,解决办法就是将symbol_t该为unsigned short类型。
如果程序是这么的简单,那么即便一眼看不出来,稍微F10调试一下也就知道bug所在了。可是在一个很大的工程项目中找到这个低级bug还是稍有困难的,尤其是for语句非常长。说起这个bug,其实本来是没有的,是我自己后来添加的,本来我是这么定义symbol_t的:typedef unsigned symbol_t; unsigned默认是unsigned int,所以不会出现任何问题,由于我的工程是space-sensitive,一直想法子节省空间,然后想到c的变量只能取0 - 255,为什么要用int这么大的范围呢?一个c无所谓,但我的项目中有N
* 256个c,N的范围可能非常大,因此觉得也许能节省点空间吧,于是就自以为是的将其改为unsigned char类型了,调试了好几个小时,真是不吐不快。
好了,昨天调了一天的bug,没好好过节,今天要好好补一下,团购了3.7元的KTV和3.7元的电影票,下午去和最好的朋友一起消费咯~~~
static OSStatus SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams, uint8_t *signature, UInt16 signatureLen) { OSStatus err; ... if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail; if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) goto fail; err = sslRawVerify(ctx, ctx->peerPubKey, dataToSign, /* plaintext */ dataToSignLen, /* plaintext length */ signature, signatureLen); if(err) { sslErrorLog("SSLDecodeSignedServerKeyExchange: sslRawVerify " "returned %d\n", (int)err); goto fail; } fail: SSLFreeBuffer(&signedHashes); SSLFreeBuffer(&hashCtx); return err;
相信眼尖的人一眼就能看出问题所在:第二个if语句处出现了两个goto fail; 因为if语句没有加大括号,所以,只有第一个goto是属于if的,而第二个goto则是永远都会被执行到的(注:这里不是Python是C语言,缩进不代表这个语句属于同一个语句块)。也就是说,就算是前面的if检查都失败了(err == 0),也会goto fail,关于这个低级bug的详细分析请看大牛陈皓写的文章“由苹果的低级Bug想到的编程思考”,很值得一读。
话虽这样讲,但哪个程序员的生命中没出现过几个低级bug呢?这些bug真是折磨的我们痛苦不已,但同时也加深了与code的感情。
比如昨天,作为一个还算细心的程序媛(@程序媛敏敏)也被一个低级bug摧残的连自己的节日都没好好过
。
看下面的code,你说说会输出多少个“Alexia”呢?
#include <stdio.h> #define CSIZE 256 typedef unsigned char symbol_t; int main() { for(symbol_t c = 0; c < CSIZE; c++) { printf("Alexia\n"); } return 0; }
哎,咋一眼都觉得输出256个“Alexia”,当然事实并非如此。
注意这里symbol_t为unsigned char类型,也就是symbol_t类型的变量c取值范围为0 - 255,当超过255就溢出了,不会变成256而是截断最高位重新变回0,即c=255后当c++时就变成0了,所以c永远小于CSIZE,这个循环也就永远不能结束,过不了好久程序就崩溃了,解决办法就是将symbol_t该为unsigned short类型。
如果程序是这么的简单,那么即便一眼看不出来,稍微F10调试一下也就知道bug所在了。可是在一个很大的工程项目中找到这个低级bug还是稍有困难的,尤其是for语句非常长。说起这个bug,其实本来是没有的,是我自己后来添加的,本来我是这么定义symbol_t的:typedef unsigned symbol_t; unsigned默认是unsigned int,所以不会出现任何问题,由于我的工程是space-sensitive,一直想法子节省空间,然后想到c的变量只能取0 - 255,为什么要用int这么大的范围呢?一个c无所谓,但我的项目中有N
* 256个c,N的范围可能非常大,因此觉得也许能节省点空间吧,于是就自以为是的将其改为unsigned char类型了,调试了好几个小时,真是不吐不快。
好了,昨天调了一天的bug,没好好过节,今天要好好补一下,团购了3.7元的KTV和3.7元的电影票,下午去和最好的朋友一起消费咯~~~
相关文章推荐
- innerHTML 和 getElementsByName 在IE下面的bug 的解决
- ListView 中的一个低级 BUG
- innerHTML 和 getElementsByName 在IE下面的bug 的解决
- 自己写的duilib树控件,如发现BUG和可优化地方请在下面回复
- ie下面,没有背景色的bug
- 由苹果的低级Bug想到的
- 由苹果的低级Bug想到的
- ie9下面的console的bug
- SQL优化【基础03】 - 从执行计划中看出问题所在及对应解决办法
- 由苹果的低级Bug想到的
- 字符串不进行初始化,那就等着bug蹦出来吧! (也谈程序为啥经常出现“烫烫烫烫烫烫”)
- cocos2dx 3.5 VS2013 release模式下面编译不通过的bug
- Win10更新时出现低级Bug:无法安装更新 电脑已关闭
- 分配了任务,但是后面又来了事情,比如多出来的bug,客户多出的要求,下面的人员又现有的安排,大部分人会抵触,因为手上有事情了,上级也不会安排人给你因为他也要挣钱
- CUDA 在 suse10.3下面的安装 (自己的安装过程,没有对其他的想法或可能存在的bug进行测试)
- 打开Word2003时出现“无法访问您试图使用功能所在的网络位置”请按确定重试,或在下面框中输入包含安装程序包genko.msi的文件夹的路径.
- 所有的bug都修正了,下面该作什么?
- 一个超低级的BUG,令我郁闷到极点
- 可是把ie67下面的bug改好了,其实很简单,ie67下面取出来的字符串是带有空格的,不知道为什么
- PHPCMS V9.3.2用户注册模板中的一个低级Bug