C语言的整型溢出问题

C语言的整型溢出问题

整型溢出有点老生常谈了,bla, bla, bla… 但似乎没有引起多少人的重视。整型溢出会有可能导致缓冲区溢出,缓冲区溢出会导致各种黑客攻击,比如最近OpenSSL的heartbleed事件,就是一个buffer overread的事件。在这里写下这篇文章,希望大家都了解一下整型溢出,编译器的行为,以及如何防范,以写出更安全的代码。

什么是整型溢出

C语言的整型问题相信大家并不陌生了。对于整型溢出,分为无符号整型溢出和有符号整型溢出。

对于unsigned整型溢出,C的规范是有定义的——“溢出后的数会以2^(8*sizeof(type))作模运算”,也就是说,如果一个unsigned char(1字符,8bits)溢出了,会把溢出的值与256求模。例如:

unsigned char x = 0xff;
printf("%d\n", ++x);

上面的代码会输出:0 (因为0xff + 1是256,与2^8求模后就是0)

对于signed整型的溢出,C的规范定义是“undefined behavior”,也就是说,编译器爱怎么实现就怎么实现。对于大多数编译器来说,算得啥就是啥。比如:

signed char x =0x7f; //注:0xff就是-1了,因为最高位是1也就是负数了
printf("%d\n", ++x);

上面的代码会输出:-128,因为0x7f + 0x01得到0x80,也就是二进制的1000 0000,符号位为1,负数,后面为全0,就是负的最小数,即-128。

另外,千万别以为signed整型溢出就是负数,这个是不定的。比如:

signed char x = 0x7f;
signed char y = 0x05;
signed char r = x * y;
printf("%d\n", r);

上面的代码会输出:123

相信对于这些大家不会陌生了。

整型溢出的危害

下面说一下,整型溢出的危害。

示例一:整形溢出导致死循环
 ... ...
... ...
short len = 0;
... ...
while(len< MAX_LEN) {
    len += readFromInput(fd, buf);
    buf += len;
}

上面这段代码可能是很多程序员都喜欢写的代码(我在很多代码里看到过多次),其中的MAX_LEN 可能会是个比较大的整型,比如32767,我们知道short是16bits,取值范围是-32768 到 32767 之间。但是,上面的while循环代码有可能会造成整型溢出,而len又是个有符号的整型,所以可能会成负数,导致不断地死循环。

示例二:整形转型时的溢出
int copy_something(char *buf, int len)
{
    #define MAX_LEN 256
    char mybuf[MAX_LEN];
     ... ...
     ... ...

     if(len > MAX_LEN){ // <---- [1]
         return -1;
     }

     return memcpy(mybuf, buf, len);
}

上面这个例子中,还是[1]处的if语句,看上去没有会问题,但是len是个signed int,而memcpy则需一个size_t的len,也就是一个unsigned 类型。于是,len会被提升为unsigned,此时,如果我们给len传一个负数,会通过了if的检查,但在memcpy里会被提升为一个正数,于是我们的mybuf就是overflow了。这个会导致mybuf缓冲区后面的数据被重写。

示例三:分配内存

关于整数溢出导致堆溢出的很典型的例子是,OpenSSH Challenge-Response SKEY/BSD_AUTH 远程缓冲区溢出漏洞。下面这段有问题的代码摘自OpenSSH的代码中的auth2-chall.c中的input_userauth_info_response() 函数:

nresp = packet_get_int();
if (nresp > 0) {
    response = xmalloc(nresp*sizeof(char*));
    for (i = 0; i < nresp; i++)
        response[i] = packet_get_string(NULL);
}

上面这个代码中,nresp是size_t类型(size_t一般就是unsigned int/long int),这个示例是一个解数据包的示例,一般来说,数据包中都会有一个len,然后后面是data。如果我们精心准备一个len,比如:1073741825(在32位系统上,指针占4个字节,unsigned int的最大值是0xffffffff,我们只要提供0xffffffff/4 的值——0x40000000,这里我们设置了0x4000000 + 1), nresp就会读到这个值,然后nrespsizeof(char)就成了 1073741825 * 4,于是溢出,结果成为了 0x100000004,然后求模,得到4。于是,malloc(4),于是后面的for循环1073741825 次,就可以干环事了(经过0x40000001的循环,用户的数据早已覆盖了xmalloc原先分配的4字节的空间以及后面的数据,包括程序代码,函数指针,于是就可以改写程序逻辑。关于更多的东西,你可以看一下这篇文章《Survey of Protections from Buffer-Overflow Attacks》)。

示例四:缓冲区溢出导致安全问题
int func(char *buf1, unsigned int len1,
         char *buf2, unsigned int len2 )
{
   char mybuf[256]; 

   if((len1 + len2) > 256){    //<--- [1]
       return -1;
   } 

   memcpy(mybuf, buf1, len1);
   memcpy(mybuf + len1, buf2, len2); 

   do_some_stuff(mybuf); 

   return 0;
}

上面这个例子本来是想把buf1和buf2的内容copy到mybuf里,其中怕len1 + len2超过256 还做了判断,但是,如果len1+len2溢出了,根据unsigned的特性,其会与2^32求模,所以,基本上来说,上面代码中的[1]处有可能为假的。(注:通常来说,在这种情况下,如果你开启-O代码优化选项,那个if语句块就全部被和谐掉了——被编译器给删除了)比如,你可以测试一下 len1=0x104, len2 = 0xfffffffc 的情况。

示例五:size_t 的溢出
for (int i= strlen(s)-1;  i>=0; i--)  { ... }
for (int i=v.size()-1; i>=0; i--)  { ... }

上面这两个示例是我们经常用的从尾部遍历一个数组的for循环。第一个是字符串,第二个是C++中的vector容器。strlen()和vector::size()返回的都是 size_t,size_t在32位系统下就是一个unsigned int。你想想,如果strlen(s)和v.size() 都是0呢?这个循环会成为个什么情况?于是strlen(s) – 1 和 v.size() – 1 都不会成为 -1,而是成为了 (unsigned int)(-1),一个正的最大数。导致你的程序越界访问。

这样的例子有很多很多,这些整型溢出的问题如果在关键的地方,尤其是在搭配有用户输入的地方,如果被黑客利用了,就会导致很严重的安全问题。

关于编译器的行为

在谈一下如何正确的检查整型溢出之前,我们还要来学习一下编译器的一些东西。请别怪我罗嗦。

编译器优化

如何检查整型溢出或是整型变量是否合法有时候是一件很麻烦的事情,就像上面的第四个例子一样,编译的优化参数-O/-O2/-O3基本上会假设你的程序不会有整形溢出。会把你的代码中检查溢出的代码给优化掉。

关于编译器的优化,在这里再举个例子,假设我们有下面的代码(又是一个相当相当常见的代码):

int len;
char* data;

if (data + len < data){
    printf("invalid len\n");
    exit(-1);
}

上面这段代码中,len 和 data 配套使用,我们害怕len的值是非法的,或是len溢出了,于是我们写下了if语句来检查。这段代码在-O的参数下正常。但是在-O2的编译选项下,整个if语句块被优化掉了。

你可以写个小程序,在gcc下编译(我的版本是4.4.7,记得加上-O2和-g参数),然后用gdb调试时,用disass /m命信输出汇编,你会看到下面的结果(你可以看到整个if语句块没有任何的汇编代码——直接被编译器和谐掉了):

7 int len = 10;
8 char* data = (char *)malloc(len);
0x00000000004004d4 <+4>: mov $0xa,%edi
0x00000000004004d9 <+9>: callq 0x4003b8 <[email protected]>

9
10 if (data + len < data){
11 printf("invalid len\n");
12 exit(-1);
13 }
14
15 }
0x00000000004004de <+14>: add $0x8,%rsp
0x00000000004004e2 <+18>: retq

对此,你需要把上面 char* 转型成 uintptr_t 或是 size_t,说白了也就是把char*转成unsigned的数据结构,if语句块就无法被优化了。如下所示:

if ((uintptr_t)data + len < (uintptr_t)data){
    ... ...
}

关于这个事,你可以看一下C99的规范说明《 ISO/IEC 9899:1999 C specification 》第 §6.5.6 页,第8点,我截个图如下:(这段话的意思是定义了指针+/-一个整型的行为,如果越界了,则行为是undefined)

注意上面标红线的地方,说如果指针指在数组范围内没事,如果越界了就是undefined,也就是说这事交给编译器实现了,编译器想咋干咋干,那怕你想把其优化掉也可以。在这里要重点说一下,C语言中的一个大恶魔—— Undefined! 这里都是“野兽出没”的地方,你一定要小心小心再小心

花絮:编译器的彩蛋

上面说了所谓的undefined行为就全权交给编译器实现,gcc在1.17版本下对于undefined的行为还玩了个彩蛋(参看Wikipedia)。

下面gcc 1.17版本下的遭遇undefined行为时,gcc在unix发行版下玩的彩蛋的源代码。我们可以看到,它会去尝试去执行一些游戏NetHack, Rogue 或是Emacs的 Towers of Hanoi,如果找不到,就输出一条NB的报错。

execl("/usr/games/hack", "#pragma", 0); // try to run the game NetHack
execl("/usr/games/rogue", "#pragma", 0); // try to run the game Rogue
// try to run the Tower's of Hanoi simulation in Emacs.
execl("/usr/new/emacs", "-f","hanoi","9","-kill",0);
execl("/usr/local/emacs","-f","hanoi","9","-kill",0); // same as above
fatal("You are in a maze of twisty compiler features, all different");

正确检测整型溢出

在看过编译器的这些行为后,你应该会明白——“在整型溢出之前,一定要做检查,不然,就太晚了”。

我们来看一段代码:

 void foo(int m, int n)
{
    size_t s = m + n;
    .......
}

上面这段代码有两个风险:1)有符号转无符号2)整型溢出。这两个情况在前面的那些示例中你都应该看到了。所以,你千万不要把任何检查的代码写在 s = m + n 这条语名后面,不然就太晚了。undefined行为就会出现了——用句纯正的英文表达就是——“Dragon is here”——你什么也控制不住了。(注意:有些初学者也许会以为size_t是无符号的,而根据优先级 m 和 n 会被提升到unsigned int。其实不是这样的,m 和 n 还是signed int,m + n 的结果也是signed int,然后再把这个结果转成unsigned int 赋值给s)

比如,下面的代码是错的:

 void foo(int m, int n)
{
    size_t s = m + n;
    if ( m>0 && n>0 && (SIZE_MAX - m < n) ){
        //error handling...
    }
}

上面的代码中,大家要注意 (SIZE_MAX – m < n) 这个判断,为什么不用m + n > SIZE_MAX呢?因为,如果 m + n 溢出后,就被截断了,所以表达式恒真,也就检测不出来了。另外,这个表达式中,m和n分别会被提升为unsigned。

但是上面的代码是错的,因为:

1)检查的太晚了,if之前编译器的undefined行为就已经出来了(你不知道什么会发生)。

2)就像前面说的一样,(SIZE_MAX – m < n) 可能会被编译器优化掉。

3)另外,SIZE_MAX是size_t的最大值,size_t在64位系统下是64位的,严谨点应该用INT_MAX或是UINT_MAX

 所以,正确的代码应该是下面这样:

 void foo(int m, int n)
{
    size_t s = 0;
    if ( m>0 && n>0 && ( UINT_MAX - m < n ) ){
        //error handling...
        return;
    }
    s = (size_t)m + (size_t)n;
}

在《苹果安全编码规范》(PDF)中,第28页的代码中:

如果n和m都是signed int,那么这段代码是错的。正确的应该像上面的那个例子一样,至少要在nm时要把 n 和 m 给 cast 成 size_t。因为,nm可能已经溢出了,已经undefined了,undefined的代码转成size_t已经没什么意义了。(如果m和n是unsigned int,也会溢出),上面的代码仅在m和n是size_t的时候才有效。

不管怎么说,《苹果安全编码规范》绝对值得你去读一读。

二分取中搜索算法中的溢出

我们再来看一个二分取中搜索算法(binary search),大多数人都会写成下面这个样子:

int binary_search(int a[], int len, int key)
{
    int low = 0; 
    int high = len - 1; 

    while ( low<=high ) {
        int mid = (low + high)/2;
        if (a[mid] == key) {
            return mid;
        }
        if (key < a[mid]) {
            high = mid - 1;
        }else{
            low = mid + 1;
        }
    }
    return -1;
}

上面这个代码中,你可能会有这样的想法:

1) 我们应该用size_t来做len, low, high, mid这些变量的类型。没错,应该是这样的。但是如果这样,你要小心第四行 int high = len -1; 如果len为0,那么就“high大发了”。

2) 无论你用不用size_t。我们在计算mid = (low+high)/2; 的时候,(low + high) 都可以溢出。正确的写法应该是:

int mid = low + (high - low)/2;
上溢出和下溢出的检查

前面的代码只判断了正数的上溢出overflow,没有判断负数的下溢出underflow。让们来看看怎么判断:

对于加法,还好。

#include <limits.h>

void f(signed int si_a, signed int si_b) {
    signed int sum;
    if (((si_b > 0) && (si_a > (INT_MAX - si_b))) ||
        ((si_b < 0) && (si_a < (INT_MIN - si_b)))) {
        /* Handle error */
        return;
    }
    sum = si_a + si_b;
}

对于乘法,就会很复杂(下面的代码太夸张了):

void func(signed int si_a, signed int si_b)
{
  signed int result;
  if (si_a > 0) {  /* si_a is positive */
    if (si_b > 0) {  /* si_a and si_b are positive */
      if (si_a > (INT_MAX / si_b)) {
        /* Handle error */
      }
    } else { /* si_a positive, si_b nonpositive */
      if (si_b < (INT_MIN / si_a)) {
        /* Handle error */
      }
    } /* si_a positive, si_b nonpositive */
  } else { /* si_a is nonpositive */
    if (si_b > 0) { /* si_a is nonpositive, si_b is positive */
      if (si_a < (INT_MIN / si_b)) {
        /* Handle error */
      }
    } else { /* si_a and si_b are nonpositive */
      if ( (si_a != 0) && (si_b < (INT_MAX / si_a))) {
        /* Handle error */
      }
    } /* End if si_a and si_b are nonpositive */
  } /* End if si_a is nonpositive */

  result = si_a * si_b;
}

更多的防止在操作中整型溢出的安全代码可以参看《INT32-C. Ensure that operations on signed integers do not result in overflow

其它

对于C++来说,你应该使用STL中的numeric_limits::max() 来检查溢出。

另外,微软的SafeInt类是一个可以帮你远理上面这些很tricky的类,下载地址:http://safeint.codeplex.com/

对于Java 来说,一种是用JDK 1.7中Math库下的safe打头的函数,如safeAdd()和safeMultiply(),另一种用更大尺寸的数据类型,最大可以到BigInteger。

可见,写一个安全的代码并不容易,尤其对于C/C++来说。对于黑客来说,他们只需要搜一下开源软件中代码有memcpy/strcpy之类的地方,然后看一看其周边的代码,是否可以通过用户的输入来影响,如果有的话,你就惨了。

参考

最后, 不好意思,这篇文章可能罗嗦了一些,大家见谅。

(全文完)


关注CoolShell微信公众账号和微信小程序

(转载本站文章请注明作者和出处 酷 壳 – CoolShell ,请勿用于任何商业用途)

——=== 访问 酷壳404页面 寻找遗失儿童。 ===——
好烂啊有点差凑合看看还不错很精彩 (43 人打了分,平均分: 4.47 )
Loading...

C语言的整型溢出问题》的相关评论

  1. 示例二中,len能通过if检查,说明它转换成unsigned不大于sizeof(mybuf),所以memcpy调用还是安全的。

    1. 示例二的确如你所说,不过在以前的有些c89的编译器并不是这样的行为(应该是编译器的bug)。为了更为严谨一些,我修改了一下,检查条件不再用sizeof了,而是用一个宏。

  2. sizeof(type) 得出的值应该是type所占的字节数,要得到type所占的位(bits)还要再乘8

  3. 对于unsigned整型溢出,C的规范是有定义的——“溢出后的数会以2*sizeof(type)作模运算”, 这里溢出后数应该以 2的sizeof(type)次方作模运算吧?

  4. 第二例:
    “此时,如果我们给len传一个负数,被提升为一个正数,通过了if的检查”
    如果负数被自动提升为整数,那么是一个大于INT_MAX的值,通不过if检查的

  5. 陈老师:在gcc (GCC) 4.4.6 20110731 (Red Hat 4.4.6-3)下
    signed char x =0x7f;
    printf(“%d\n”, x+1);
    打印出128啊

  6. 示例四:缓冲区溢出导致安全问题, 这个我在VS2010中测试了一下,len1和len2均为10时和设置为250时,没有溢出现象,没有你所说的问题而全部按”预期”执行.if((len1 + len2) > 256) 这里,虽然len1和len2都是unsigned char类型,我猜在编译器看来常数256可能是整形,于是在做计算和判断时自动转成了整型了.没有时间做更深入的研究,大家有兴趣或许可以继续

    1. 不用猜,你是对的。被提升成int了。我修改了一下源文。不用unsigned char,改成unsigned int,这样就更清楚了。

  7. 文刀 :
    陈老师:在gcc (GCC) 4.4.6 20110731 (Red Hat 4.4.6-3)下
    signed char x =0x7f;
    printf(“%d\n”, x+1);
    打印出128啊

    (x+1)时x被提升成int了。试试:

    signed char x =0x7f;
    printf(“%d\n”, ++x);

  8. 您在文中提到“注意:有些初学者也许会以为size_t是无符号的,而根据优先级 m 和 n 会被提升到unsigned int。其实不是这样的,m 和 n 还是signed int,m + n 的结果也是signed int,然后再把这个结果转成unsigned int 赋值给s”,好吧,我就是初学者,我还真的是这么认为的。经过我在VS2010中的测试,好象还真的是这样的。而在前些年我写的C语言解释器中针对变量类型不一致的情况,我的处理方案就是先转成最大最精确的类型再计算(其实就是在计算的过程中按最大最精确的类型来解读)。我想不出先按原类型计算出结果后再转成新类型的理由,谁能帮我解释一下这么做的理由呢?

  9. 谷壳 :
    您在文中提到“注意:有些初学者也许会以为size_t是无符号的,而根据优先级 m 和 n 会被提升到unsigned int。其实不是这样的,m 和 n 还是signed int,m + n 的结果也是signed int,然后再把这个结果转成unsigned int 赋值给s”,好吧,我就是初学者,我还真的是这么认为的。经过我在VS2010中的测试,好象还真的是这样的。而在前些年我写的C语言解释器中针对变量类型不一致的情况,我的处理方案就是先转成最大最精确的类型再计算(其实就是在计算的过程中按最大最精确的类型来解读)。我想不出先按原类型计算出结果后再转成新类型的理由,谁能帮我解释一下这么做的理由呢?

    “m + n”是个表达式,而”s = xxx”是另一个表达式;隐式类型转换肯定是先发生在优先级更高的表达式内,赋值表达式优先级最低,因此先进行”m + n”的类型推导,结论是,双方都是int无需转换,然后再处理表达式”size_t = int”将右边类型提升

    而你的设想则是反过来,根据优先级最低的表达式得到最大类型,再由外向内将各个更高优先级进行类型扩展后才开始算数运算…这才是奇怪哦
    “sqrt(i1 / i2)”,结果可能对一个小数开方哦…

  10. 《苹果安全编码规范》那段有点没看明白
    连续判断了n>0 m>0 而且 SIZE_MAX/n >m, n是整数则除法不应该溢出…
    能不能举个简单的反例? 多谢

  11. void foo(int m, int n)
    {
        size_t s = 0;
        if ( m>0 && n>0 && ( UINT_MAX - m < n ) ){
            //error handling...
            return;
        }
        s = (size_t)m + (size_t)n;
    }

    里面,UINT_MAX 换成 SIZE_MAX 也是可以的,因为后面已经把两个数转换成 size_t 了,所以即使 m + n 会溢出,(size_t)m + (size_t)n 也不会溢出。

  12. 陈皓 :
    不用猜,你是对的。被提升成int了。我修改了一下源文。不用unsigned char,改成unsigned int,这样就更清楚了。

    印象中char/unsigned char溢出会涉及到C99中整形提升的概念,保证中间变量不会溢出.所以此处char不会有问题.
    但是int/unsigned int溢出会出现问题.

  13. Scan :

    谷壳 :
    您在文中提到“注意:有些初学者也许会以为size_t是无符号的,而根据优先级 m 和 n 会被提升到unsigned int。其实不是这样的,m 和 n 还是signed int,m + n 的结果也是signed int,然后再把这个结果转成unsigned int 赋值给s”,好吧,我就是初学者,我还真的是这么认为的。经过我在VS2010中的测试,好象还真的是这样的。而在前些年我写的C语言解释器中针对变量类型不一致的情况,我的处理方案就是先转成最大最精确的类型再计算(其实就是在计算的过程中按最大最精确的类型来解读)。我想不出先按原类型计算出结果后再转成新类型的理由,谁能帮我解释一下这么做的理由呢?

    “m + n”是个表达式,而”s = xxx”是另一个表达式;隐式类型转换肯定是先发生在优先级更高的表达式内,赋值表达式优先级最低,因此先进行”m + n”的类型推导,结论是,双方都是int无需转换,然后再处理表达式”size_t = int”将右边类型提升
    而你的设想则是反过来,根据优先级最低的表达式得到最大类型,再由外向内将各个更高优先级进行类型扩展后才开始算数运算…这才是奇怪哦
    “sqrt(i1 / i2)”,结果可能对一个小数开方哦…

    参考 整型提升

  14. size_t 是由编译器参数决定sign还是unsign的.
    所以具体还是要看编译选项.尤其是嵌入式编译器.
    曾经碰到不同的编译器,同样的char型,默认一个(TI IAR)解释为unsigned,一个(日本瑞萨)解释为signed,需要勾选相关选项才行.

  15. 这几天在看《深入理解计算机系统》,里面就提到了四则运算的溢出问题

  16. Scan :

    谷壳 :
    您在文中提到“注意:有些初学者也许会以为size_t是无符号的,而根据优先级 m 和 n 会被提升到unsigned int。其实不是这样的,m 和 n 还是signed int,m + n 的结果也是signed int,然后再把这个结果转成unsigned int 赋值给s”,好吧,我就是初学者,我还真的是这么认为的。经过我在VS2010中的测试,好象还真的是这样的。而在前些年我写的C语言解释器中针对变量类型不一致的情况,我的处理方案就是先转成最大最精确的类型再计算(其实就是在计算的过程中按最大最精确的类型来解读)。我想不出先按原类型计算出结果后再转成新类型的理由,谁能帮我解释一下这么做的理由呢?

    “m + n”是个表达式,而”s = xxx”是另一个表达式;隐式类型转换肯定是先发生在优先级更高的表达式内,赋值表达式优先级最低,因此先进行”m + n”的类型推导,结论是,双方都是int无需转换,然后再处理表达式”size_t = int”将右边类型提升
    而你的设想则是反过来,根据优先级最低的表达式得到最大类型,再由外向内将各个更高优先级进行类型扩展后才开始算数运算…这才是奇怪哦
    “sqrt(i1 / i2)”,结果可能对一个小数开方哦…

    我错了,受前面的影响把“signed int”看成了“signed char”,面壁去。

  17. 看了博客,第一反应是整形提升的问题。对于代码中的数字常量,一般会用int来表示。当表示范围低于int类型的变量参加运算或者传递参数时会进行整形提升。当然已经有人指出了,这里我补充一个小点,并且有一个牛的测试网址,希望对大家有帮助。

    unsigned char x = 0xff
    这就是为什么:x++,x+1等的值是一个正确的值。但是++x却符合作者的意图,这应该是后置和前置的区别把。

    short y = 1;
    y = y + 1; // 会有警告,精度丢失的可能
    y += 1; // 没有警告

    在《鸟哥Linux私房菜》中有一篇就是讲解整型提升的问题。整型提升的问题。当有符号数和无符号数进行大小比较时,这里会存在一个大坑:

    1. 有符号数的范围比无符号数表示范围大(有符号数可以表示无符号数),Ok,这个没事。
    2. 有符号数表示的范围范围没有无符号数大(有符号数的精度无法表示无符号数),那么此时有符号数会用无符号数的精度来表示,即通过+/- 2^n来快速进入无符号数的范围(都是整数就无所谓了)。这样你会看见负数会大于整数的结果。

    #include <iostream>
    #include <climits>
    using namespace std;
    
    int main()
    {
        int x = -1;
        int z = 1;
        unsigned long y = INT_MAX + 1;
        if (x > y)
        {
            cout << "BINGO" << endl;
        }
        
        if (z < y)
        {
            cout << "BINGO" << endl;
        }
        return EXIT_SUCCESS;
    }

    你懂整数么?那么来测试一下。这个国外人整理的测试。
    http://blog.regehr.org/archives/721

    B.R.

  18. matt :
    示例4不太懂,len1+len2的时候不会提升到int型吗,那个if怎么会被优化呢

    没事了,网页放了半天没刷新

  19. 我试了一下编译器优化的那个示例。的确,gcc 会把 if (data + len 0x7fff){
    puts(“overflow!”);
    }
    printf(“%hd + %hd = %d\n”, a, b, a + b);
    return 0;
    }

    我用的是 gcc 4.8.2。

  20. 永远都不要用unsigned,对待项目代码已有的unsigned要小心,不要贪恋正整形两倍的表示空间,也不要代码文档化地告诉其他人这个是正整型。

  21. 示例四中说“被编译器给删除了”,我觉得容易让人误解——好像是在说编译器会在编译的时候就把它优化去掉

  22. 我记得以前Google的C++代码规范里说过用整数的原则:一是除非表示位组,否则不要用无符号数。需要进行算术计算的数字一概用有符号,就是为了一定程度上避免整数转型出乎意料。然后如果有32位溢出的可能,就上64位。就现在来说除非科学计算,一般不至于连64位的int64_t都会溢出。

  23. 另外,微软的SafeInt类是一个可以帮你远理上面这些很tricky的类,下载地址:http://safeint.codeplex.com/

    「远理」->「远离」?

  24. 示例一的算法对么,len代表读的总长度,buf每次都累加上,好像不对吧,是不是应该改成
    len += readFromInput(fd, buf+len);

  25. 在《苹果安全编码规范》(PDF)中,第28页的代码中:
    if (n > 0 && m > 0 && SIZE_MAX/n >= m) {
    size_t bytes = n * m;
    }

    没发现什么问题, linux/unix系统 SIZE_MAX定为机器字长所表示的最大值与size_t的最大值相同,请问耗哥我的解释有不妥之处没?

  26. 耗兄:

    不好意思,给你挑个问题。编译器优化一节下的例子我认为是错误的。我尝试了一下,按你的写法,-O2确实会把if优化掉,但原因是len都没有初始化!如果data和len是函数的参数的话,if块完全没有问题。如果len是一个可能为负的算式的话,if块也没有问题。

  27. @9drops

    @kurk

    我一开始也觉得没问题,仔细看了之后,发现如果n和m是32位整数而系统是64位的话,还是会出问题。比如,n=0x10000,m=0x10001,在64位系统上会得到bytes=65536而不是出错。用UINT_MAX替换SIZE_MAX可以解决这个问题。

grissiom进行回复 取消回复

您的电子邮箱地址不会被公开。 必填项已用*标注