CSAPP 读书笔记：C语言中TMin的写法

本文为CSAPP2e的webaside资料，随意翻译，无版权。原文

1.情景
在CSAPP的图示和问题中，我们很小心的把32(TMin32)位有符号最小值写作-2147483647-1,为什么我们不直接写成-2147483648或0x80000000呢?不妨先打开limits.h头文件看看吧，你会发现它们也是用类似的诡异形式

ISO90:
Decimal: int | long | unsigned | long long
Hexadecimal: int | unsigned | long | unsigned long
ISO99:
Decimal: int | long | long long
Hexadecimal: int | unsigned | long | unsigned long | long long | unsigned long long
上面的表格是整形常量的数据类型表示，根据语言版本和格式(10进制和16进制)，常量的数据类型会从上面表格里选择第一个最合适的类型。

因此，根据上述标准的话，我们可以得到如下结论:

ISO90: ISO 99:
常量表达式 －2147483648 0x80000000 -2147483648 0x80000000
32位 unsigned unsigned longlong unsigned
64位 long unsigned long unsigned
上面的表格是TMin32的数据类型表示。根据语言版本和格式，我们获得了这两种表达式的三种不同的数据类型，注意里面包括非负值值

因此定义signed int的最大值和最小值，采用如下方式
#defineINT_MAX 2147483647
#defineINT_MIN -INT_MAX-1

很不幸的因为二进制补码的数值表示不对称性，我们不得不在C语言中如此怪异地定义TMin，尽管要理解这点我们必须挖掘C预言标准中最阴暗的角落之一，这也有助于让我们更好的鉴识整形的数据类型和表示方法。

假如我们直接将TMin定义为-2147483648，那么在32位机器上编译这样的代码，编译器遇到型如-X的数值，它首先会确定X的数据类型，然后取X的负数。而2147483648对于int类型是在太大了，编译器就会再次尝试一种类型可以正确的表示此值。然后它就会按照第一个表格的顺序往下继续尝试类型，再假设编译器采用的标准是ISOC90，int的下一个类型是long，再下一个是unsigned，然后就发现unsigned是第一个合适的数据类型。正如我们知道的，21473648和-2147483648在32位数值上拥有同样的内存表示，这也导致此常量的数据类型是unsigned且值为2147483648。而ISOC99的情况则是按照上述规则数据类型为long long才能容纳2147483648。64位的情况因为2147483648与－2147483648可以表达为不同的内存表示，所以仍然按照规矩来此常量的数据类型为longlong值为－2147483648。


对于十六进制的的情况，常量0x80000000在32位机器上，编译器仍然是遵照类似的规则。无论是ISOC90还是ISOC99，都首先和TMax32(即0x7FFFFFFF)比较，发现较大后，得知int无法容纳本常量，接下去照着表格1就是UMax32(即0xFFFFFFFF)，发现较小，就选择了unsigned作为本常量的数据类型，因此,常量0x80000000的数据类型是unsigned的，且值为0x80000000(或者说与2147483648相同)。

事情在64位机器上稍微有些不同，无论哪个语言版本，十进制表示的TMin都是数据类型long(64位长),值为-21473648,而十六进制表示的TMin则是数据类型unsigned，值为0x80000000(与2147483648相同)。


经过上述分析后，我们就可以得到表格2了，当数据类型为long或long long的时候，常量是负的，但它也就成了64位长。而当数据类型为unsigned时，此常量时正的32位长。用下面的代码就可以表示

intdcmp = (-2147483648 < 0);
inthcmp = (0x80000000 < 0);

上面代码尝试测试十进制和十六进制表示的TMin常量是否小于0。二者取决于编译器采用的语言版本以及字长，我们发现dcomp的值有时为0有时为1，也就是十进制表示的TMin有时候为正的有时候为负的，而hcomp的值一直是0，也就是十六进制表示的TMin永远为正的。这个简单写32位有符号最小值常量的任务比我们想象中要困难的多。(据我个人测试，VC2008在32位机器上，十进制的TMin会被认为是unsigned，而gcc在64位机器上，无论是C90还是C99都认为是long，而十六进制的TMin无论字长还是编译器都一致认为是unsigned)

问题1：
考虑如下代码：
intdtmin = -2147483648;
intdcomp2 = (dtmin < 0);
inthtmin = 0x80000000;
inthcomp2 = (htmin < 0);
无论我们在32位还是64位机器，语言版本是C90还是C99,始终dcomp2和hcomp2都为1，进一步直接将dtmin以及htmin和TMin比较都是相等的，解释这为何没有像之前一样对常量有微妙的区别。

2.启示

对于大多数程序，因为字长和语言版本的不同导致的歧义并不会影响程序行为。不过我们现在已经可以了解为何将TMin32写成-2147483647-1可以获得更想要的结果了。因为TMax32的值2147483647本来就可以表示成int，所以没必要对其做类似的改写。


问题2：
假如我们把TMin32写成-0x7FFFFFFF-1,那么对于不同的字长和不同的语言版本，编译器是否会对TMin都确定同样的int数据类型呢？并尝试解释。

问题3：
你相要写一个有效的TMinW表达式，W是数值的long int类型的位数。因为数据类型在不同的机器上大小也不相同，你决定使用sizeof操作符，那么只要W是8的倍数，TMinW的表达式就呼之欲出，同时你还想来点小花招，你知道乘以8和左移3位是等效的。
你最先是这些尝试的：
/*警告，下面的代码有bug*/
/*讲1左移8*sizeof(long)-1位*/
1L<< sizeof(long) << 3 -1;
你把这段代码在32位机器上测试，发现结果为64
A.解释这是为什么
B.同样的代码在64位机器上结果是多少
C.做尽可能少的修改让其正确运作

如果懒得看我就简短说一下大意，为什么要特意把32位int的最小值常量写成-2147483647-1而不是-2147483648是因为编译器遇到-X这样的常量是先获得X的值与类型，然后再对其取负，而对于32位以上机器的所有int类型都容不下2147483648这么大，所以会再寻找更合适的数据类型来表示，而寻找合适类型这步在不同的C语言版本，不同的平台，不同的表示格式都有不同的适配顺序，这就导致了如果直接写-2147483648可能会是unsigned的，可能会是long还可能会是long long型的，故用-2147483647-1的形式来消弭此歧义。

问题的解答也没什么好说的，第一个其实就是最后来了步隐式转换，不管常量是什么类型，转化为int后那始终是-2147483648的字面值。第二题的原理就是-2147483647-1一样，自然是正确的。第三题只要改写成1L<< (sizeof(long) << 3 )-1; 即可，运算符优先级的问题。

 

转自：http://bukkake.iteye.com/blog/712953