字长、int整型与隐式类型转换

先说我之前编程的错误

例一：

u16 u16a = 0xFFFF;

u16 u16b = 0x01;

u32 u32c = 0x00;

u32sum = u16a + u16b + u32c;

                                 

u32sum是等于0x10000，还是0x0呢，

我只敢说，不知道，这和CPU的字长有关系。

 

例二：

u16 u16a = 0xFFFF;

u16 u16b = (~u16a)>>4;

u16b最终是等于多少呢，是0x0吗，会不会是0xF000呢，

我只敢说，不知道，这和CPU的字长有关系。

 

         int整型在C语言中，可能等同于short int，也可能等同于lont int。这取决于CPU的字长，16位的CPU是short int，32位的CPU是long int。其他整形操作数（char\shot\bit-field和enum）在数值操作前总是先转化为int或unsigned int类型。

         整数提升的规则是，如果int类型能够代表原来类型的所有值，那么small interger就会隐性提升为int类型，否则就会转化为unsigned int。

         这一隐式的类型转换会带来许多的潜在的风险。

 

         先看第一例子，

         u32sum = u16a + u16b + u32c;

         在32位CPU中，u16a、u16b在运行之前，会隐式提升为s32位整型，然后再进行相应的运算，这样最终的结果是0x10000。

         在16位CPU中，u16a、u16b运行完成后，由于折叠了0x10000为0x0000，与u32c运算之前，先会进行平衡转换，转换成u32整型，最终答案是0x0。

        

         再看第二个例子。

         u16b = (~u16a)>>4;

         在16位CPU中，0xFFFF按位取反即为0x0000，再向右移位，仍为0x0000。

         在32位CPU，u16a在运算之前会进行整型提升，变成s32整型的0xFFFF，按位取反为0xFFFF0000，再向右移4位再截取，即为0xF000。