C标准库函数abs的一个错误

    VC.NET 7.1 提供的取绝对值函数(abs.c中)如下：

    int __cdecl abs (
        int number
        )
    {
        return( number>=0 ? number : -number );
    }

   此函数实现得非常简单，乍看之下无任何毛病，可是仔细琢磨琢磨，就发现了一个大漏洞。举个极端的例子，当函数参数为INT_MIN(32位的int此值为0x80000000，即–2147483648)时,对它取负会产生上溢，因为32位的int能表示的最大正数是INT_MAX(0x7fffffff，即2147483647)。实际上，对INT_MIN取负等于什么也没有干(0x80000000按照补码取负规则还是0x80000000)。因为函数声明的返回值也是int，所以大多数时候程序员会用某个int变量来接收这个返回值，但是如上所述的极端情况则几乎百分百地导致程序混乱。

    简单的解决办法就是总是用unsigned int类型的变量来接收返回值。因为32位的unsigned int的值域范围是0到4294967295(0xffffffff),2147483648落在这个范围内，所以用unsigned int变量可以正确地表达INT_MIN的绝对值。如果觉得这种做法容易忘记，还可以自己写一个abs，只需在上述函数体的前面加一句assert(number > INT_MIN)就行了，或者将返回值改成unsigned int类型。

    为什么在标准库中会出现这么隐蔽的漏洞呢？因为计算机的存储空间有限，所以C中的每种类型所占字节数也须是有限大小，这样程序语言中的类型真正能表示的值域就是对应数学类型值域的有限子集了。这就是现实与理想的差距。不仅如此，因为有符号类型比无符号类型多拨出一个二进制位来表示符号信息，则它们能表示的值域又有所差异。但是程序员写程序却往往有意或无意地忽略这种差别，不愿面对现实(正如有的程序员调用函数从不检查返回值)。他们使用程序中的类型就象在使用理想的数学上的类型一样。欧洲阿里亚纳火箭爆炸就是此种错误给我们的最惨痛教训。

    既然如此，每一个C程序员都有责任牢记这么一条规则:“经常反问：这个变量或表达式会上溢或下溢吗？”(《编程精粹－Microsoft编写优质无错C程序秘诀》P80,Steve Maguire 著)。

    补充(于2005年3月22日): ANSI C标准规定了每种整数类型的最小值域(但没有规定它们必须采用哪种编码方案)，并要求所有的C语言实现都要在limits.h头文件中通过诸如INT_MIN、INT_MAX这样的宏来指定该实现中整型数据的实际值域，而且这些实际的值域一定不能比标准规定的最小值域还要小(也即要求每种实现在limits.h中定义的宏的绝对值不小于C标准规定的同名宏的绝对值，并且正负号要保持一致)。标准定义的INT_MIN是-(2^15 - 1)，INT_MAX是(2^15 - 1)，换句话说，标准保证了int型数据至少能表示-(2^15 - 1)到(2^15 - 1)这样一个对称区间内的所有整数，因此程序员可以放心大胆地用int变量存储以上范围内的任何整数。但与此同时请特别注意，用int变量表达超出上述范围的数将是一件没有法律(标准即是程序员的法律)保障的事情，所以不应该想当然地认为-32768(即-2^15)一定可以用int型来表达，尽管它确实位于用二次补码记法(twos-complement notation)进行编码的16位整数的值域内。熟悉以上背景后再回顾abs函数的问题就会发现，实际上该函数对于标准规定范最小值域内的所有整数都能正常工作，而上面提到的引起错误的输入数据已经不在此范围内了，所以此错误不应由abs而应由函数调用者负责。由此可见，为了安全以及可移植性，将表达式欲表示的值严格限制在标准指定的最小值域内是一个良好的编程习惯。