类型转换对于不同的编译器给出不同的结果。

Question

这只是一个基本的东西，但仍然与此混淆。

我的代码由一行组成

signed char var = 0x80;
unsigned short temp_val;
temp_val = (unsigned short)var ;

当我使用XC32编译器编译这段代码并执行该程序时，得到的结果与预期的0xFF80相同。

但是在使用CCS编译器进行MSP430编译时，得到的结果是0x0080。

为什么在编译器方面存在这种差异？

有人能从处理器的角度解释一下这种类型铸造吗？

Answer 1

这是有符号整数溢出，因为0x80 = 128，如果CHAR_BIT是8，那么signed char只会上升到127。

signed char var = 0x80;

有符号整数溢出会产生未定义的行为。

尝试使用signed char var = -128代替。

如果这会产生相同的结果，那就是编译器的错误。将负数转换为unsigned类型将其从对应的模数中减去，该模数大于该类型的最大值。

Answer 2

如果char的位数超过8位，这种情况就会发生，这当然是允许的。(不能再少了。)如果short结果只有8位，这不符合标准C，但CCS编译器只声称符合"97%“，也会发生这种情况。

各种整数数据类型的大小受处理器的限制，但最终由编译器定义，编译器甚至可能有更改大小的选项。

我对MSP430一无所知，但谷歌告诉我这是一个16位芯片。它的内存可能不是字节可寻址的，在这种情况下，char必须占用整个16位。(编辑：很明显，它是字节可寻址的，所以不要理会这个理论。)

Answer 3

任何字符都可以是，到编译器，不同的长度取决于编译器的设置，包括7位(现在很少)，8位(大多数人认为是这样)，16位(特别是在Unicode中变得更常见)，我甚至遇到了机器/编译器组合，将每个字符存储在64位位置。

编译器之间的这种差异就是为什么MISRA C有反对以下内容的规则：

• 基型
• 符号类型上的位操作

仅仅因为芯片是字节可寻址的，这并不意味着任何给定的编译器都会这样使用，默认情况下是，因为16或更大的存储系统上的字节操作可能会导致处理开销，一些编译器默认使用内存大小操作来优化速度而不是存储。

我建议搜索pack的编译器文档。

几年前，默认的Solaris编译器对位字段中的每个字段使用了64位位置--幸运的是，Solaris gcc没有这样做，所以我们能够完成这个项目。

同样有趣的是：

signed char var = 0x80;
signed short temp_val1;
unsigned short temp_val2;

temp_val1 = (signed short)var ;
temp_val2 = (unsigned short)temp_val1;

这可能会突出显示编译器中符号扩展的问题。