c - 为什么 char 与 signed char 或 unsigned char 不兼容？

Question

我发现C99标准有一条声明否认char类型和signed char/unsigned char类型之间的兼容性。

C99标准注释35:

CHAR_MIN, defined in limits.h, will have one of the values 0 or SCHAR_MIN, and this can be used to distinguish the two options. Irrespective of the choice made, char is a separate type from the other two and is not compatible with either.

我的问题是为什么委员会否认兼容性？这是什么道理？如果 char 兼容 signed char 或 unsigned char，会不会有什么可怕的事情发生？

Answer 1

根源在于编译器历史。八十年代基本上有两种 C 方言:

1. 签署普通字符的地方
2. 其中普通 char 是无符号的

C89 应该标准化哪些？ C89 选择既不标准化，因为它会使已经编写的 C 代码中所做的大量假设无效——标准人员称之为安装基础。所以 C89 做了 K&R 所做的事情:保留普通 char 实现定义的符号。如果您需要特定的签名，请限定您的字符。现代编译器通常让您通过选项选择方言(例如 gcc 的 -funsigned-char)。

如果您忽略 (un)signed char 和普通 char 之间的区别，可能会发生“可怕”的事情是，如果您在不考虑这些细节的情况下进行算术和移位，您可能会在不考虑这些细节的情况下得到符号扩展期望它们，反之亦然(甚至在移动时出现未定义的行为)。

还有一些愚蠢的建议，建议始终使用显式有符号或无符号限定符声明您的字符。只要您只使用指向此类限定类型的指针，它就可以工作，但是当您处理字符串和字符串函数时，它需要丑陋的强制转换，所有这些都对指向普通字符的指针进行操作，如果没有强制转换，它是赋值不兼容的。这样的代码突然被大量丑陋到骨子里的铸件所覆盖。

字符的基本规则是:

• 对字符串使用普通 char，如果您需要将指针传递给采用普通 char 的函数
• 如果需要对字节进行位操作和移位，请使用unsigned char
• 如果您需要较小的有符号值，请使用 signed char，但如果空间不是问题，请考虑使用 int