为什么char的符号没有在C中定义？答案

【问题标题】：why is char's sign-ness not defined in C?为什么char的符号没有在C中定义？
【发布时间】：2010-10-29 04:37:22
【问题描述】：

C 标准规定：

ISO/IEC 9899:1999, 6.2.5.15（第 49 页）

三种类型 char、signed char 和 unsigned char 统称为字符类型。这实现应将 char 定义为具有相同的范围，表示，和行为作为有符号字符或无符号字符。

确实 gcc 根据目标平台定义。

我的问题是，为什么标准会这样做？除了可怕且难以发现的错误之外，我看不到任何来自模棱两可的类型定义的东西。

不仅如此，在 ANSI C（C99 之前）中，唯一的字节大小类型是 char，因此有时不可避免地使用 char 进行数学运算。所以说“一个人永远不应该将 char 用于数学”并不是那么正确。如果是这种情况，更明智的决定是包含三种类型“char,ubyte,sbyte”。

这是有原因的，还是只是一些奇怪的向后兼容问题，以便允许将糟糕（但常见）的编译器定义为标准兼容？

【问题讨论】：

Any compiler which takes 'char' as 'unsigned'?
Why don't the C or C++ standards explicitly define char as signed or unsigned?。因为在某些架构上 unsigned char 更有效，而在另一些架构上则相反

标签： c gcc standards char unsigned

【解决方案1】：

我想（不由自主地）他们的想法是这样的：

如果您关心 char 的符号（将其用作字节），您应该明确选择有符号或无符号字符。

【讨论】：

未签名后来出现；签署的时间比那晚了很多。

【解决方案2】：

也许历史上有些实现的“char”是有符号的，有些是无符号的，因此为了与两者兼容，他们不能将其定义为一个或另一个。

【讨论】：

正确。在当前每个处理器都是 x86、Power 或 Sparc 的世界中，很难说在 70 年代有数十种不同架构的处理器可用。从 8 位 DEC 的优雅简洁到 36 位庞然大物的怪物洞穴。甚至没有就字符的大小达成一致——施乐机器使用 6 位字符集。
为什么机器会关心字符？是否有 CPU 命令输出字符？我在 x86 中不知道这样的事情。
是的，原因是历史原因。然后，由于我们有 unsigned char/signed char/plain char——出于对称原因，我们也有signed int/short——即使其他整数类型的有符号是多余的。因此，主要是打算很好地定义符号，但它不能再发生 char - 太多的代码会破坏

【解决方案3】：

具有未指定符号的“普通”字符允许编译器选择对目标体系结构更有效的表示：在某些体系结构上，零将一个字节值扩展到“int”的大小需要更少的操作（因此普通字符“无符号”），而在其他指令集使符号扩展更自然，普通字符被实现为有符号。

【讨论】：

是的，硬件提供的任何东西都应该可以直接用于该语言，并且使用最少的粘性糖。
那为什么不对未签名/签名短片重复同样的故事呢？它也应该扩展到 int。
@ElazarLeibovich 这是一个有见地的评论，但是通过使short 与int 相同的大小（例如都是16 位）来完全回避这个问题更为常见（例如都是16 位） char 与 int 大小相同，尽管两者都被 C 标准允许并且都存在于野外。 char 的签名似乎并不像 short 的签名那样重要，这使得妥协看起来更容易接受。
@ElazarLeibovich：请参阅下面的答案；字符集可能会强制char 无符号，或者char 和int 的相对范围可能会强制char 有符号。

【解决方案4】：

在过去，C 被定义，字符世界是 7 位，所以符号位可以用于其他事情（如 EOF）

【讨论】：

【解决方案5】：

在某些机器上，有符号的 char 太小，无法容纳 C 字符集中的所有字符（字母、数字、标准标点符号等）。在此类机器上，'char' 必须是无符号的。在其他机器上，unsigned char 可以保存比有符号 int 更大的值（因为 char 和 int 的大小相同）。在这些机器上，必须对“char”进行签名。

【讨论】：