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

Question

我发现C99标准有一个语句,它拒绝类型char和signed char/unsigned char类型之间的兼容性.

C99标准注35:

在limits.h中定义的CHAR_MIN将具有值0或SCHAR_MIN之一,这可用于区分这两个选项.无论做出何种选择,char都是与其他两种类型不同的类型,并且与两者都不兼容.

我的问题是为什么委员会否认兼容性？理由是什么？如果char与signed char或unsigned char兼容,会发生什么可怕的事情吗？

Answer 1

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

1. 签署普通字符的地方
2. 其中普通字符是未签名的

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

如果忽略(un)signed char和plain char之间的区别,可能发生的"可怕"事情是,如果你在不考虑这些细节的情况下进行算术和移位,那么当你不期望它们时,你可能会得到符号扩展或者反之亦然(甚至在换档时未定义的行为).

还有一些愚蠢的建议,建议总是使用显式签名或无符号限定符声明你的字符.只要您只使用指向这些限定类型的指针,这就可以工作,但是只要处理字符串和字符串函数,它就需要丑陋的强制转换,所有这些函数都在指向普通字符的情况下运行,这是指派不兼容的演员.这样的代码突然变成了大量丑陋的角色.

字符的基本规则是:

• char对于字符串使用plain ,如果需要将指针传递给使用plain char的函数
• 使用unsigned char,如果你需要做的位操作和转移的字节
• signed char如果您需要较小的有符号值,请使用,但考虑使用int空间不是问题

Answer 2

signed char将and视为最小的算术、整数unsigned char类型，就像signed short/ ，unsigned short等等。这些类型都是明确指定的。intlong intlong long int

另一方面，char它有一个非常不同的目的：它是 I/O 和与系统通信的基本类型。它不是用于计算，而是作为数据单位。这就是为什么您会char在命令行参数、“字符串”的定义、函数FILE*和其他读/写类型 IO 函数以及严格别名规则的例外中找到它。这种char类型故意不那么严格地定义，以便允许每个实现使用最“自然”的表示。

这只是一个职责分离的问题。

（不过，这确实与和都是char布局兼容的，因此您可以显式地将一个与另一个相互转换。）signed charunsigned char