与运营商<<的整数推广
类似于Bitshift和整数提升的问题？ ，我在使用左位移时有一个关于整数提升的问题。
unsigned int test(void) { unsigned char value8; unsigned int result; value8 = 0x12; result = value8 << 8; return result; } 在这种情况下，value8首先会提升为unsiged int还是具体实现？
6.5.7按位移位运算符… 3 Sematics …
对每个操作数执行整数提升。 结果的类型是提升的左操作数的类型。 如果右操作数的值为负或大于或等于提升的左操作数的宽度，则行为未定义。
它说“整数促销是在每个操作数上执行的”。 ，但这里的推广规则是什么？
我假设它应该convert to int if lesser rank than int ，但我找不到它。
我问这个，因为一个编译器（Renesas nc30wa）没有提升到int，所以我的样本结果总是0。
在这个平台上，char是8位宽，int 16位。
短语“整数促销”是一个非常具体的东西，可以在（对于C99）第6.3.1.1 Booleans, characters, and integers节中找到。 6.3.1.1 Booleans, characters, and integers ：
如果int可以表示原始类型的所有值，则该值将转换为int; 否则，它将转换为unsigned int。 这些被称为整数促销。 整数促销不会更改所有其他类型。
因此，假设您的unsigned char可以保存在int ，它将被提升为int 。 在那些罕见的平台上， unsigned char和int一样宽，它将提升为unsigned int 。
这仅在C11中略有改变：
如果int可以表示原始类型的所有值（由宽度限制，对于位字段），该值将转换为int; 否则，它将转换为unsigned int。 这些被称为整数促销。 整数促销不会更改所有其他类型。
如果特定编译器不遵循此行为，那么它并不真正符合。 但是，鉴于您列出的编译器适用于嵌入式系统，因此并不令人惊讶。
许多是为特定目的而构建的，并且在要求列表中的一致性并不总是很高。 可能存在编译器标志，使其更符合标准。
查看您的特定环境， M16C Series,R8C Family C Compiler Package V.5.45 C Compiler （参见此处 ）在2.1.4 nc30 Command Line Options中有第f. Generated code modification options f. Generated code modification options ：
-fextend_to_int（-fETI）：
将char类型数据扩展为int类型后执行操作。 根据ANSI标准进行扩展。
虽然我怀疑-fansi可能是一个更好的选择，因为它也涵盖了其他一些东西。
假设unsigned char的转换等级低于int的转换等级（通常是大多数平台上的情况）， value8被提升为int 。
整数的转换等级在6.3.1.1中的C99中描述。
请注意，默认情况下，某些编译器会禁用整数提升规则。 例如，MicroChip编译器MPLAB C18。 在编译器的文档中查找ISO一致性。