前段时间苹果公司报出了一个iOS 7.0.6的低级bug,该bug会引起中间人攻击,出现该bug的源码如下:
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;
话虽这样讲,但哪个程序员的生命中没出现过几个低级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; }
注意这里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元的电影票,下午去和最好的朋友一起消费咯~~~
也谈低级bug引来的悲伤:你能一眼看出下面的bug所在吗?,布布扣,bubuko.com
原文:http://blog.csdn.net/lanxuezaipiao/article/details/20714375