为什么char的符号在C中没有定义？ [英] why is char's sign-ness not defined in C?

问题描述

C标准规定：

ISO / IEC 9899：1999，6.2.5.15（第49页）

ISO/IEC 9899:1999, 6.2.5.15 (p. 49)

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

The three types char, signed char, and unsigned char are collectively called the character types. The implementation shall define char to have the same range, representation, and behavior as either signed char or unsigned char.

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

And indeed gcc define that according to target platform.

我的问题是，为什么标准这样做？

My question is, why does the standard do that? I can see nothing that can come out of ambiguous type definition, except of hideous and hard to spot bugs.

不仅如此，在ANSI C（C99之前）中，我们可以看到，只有字节大小的类型是char，所以使用char数学有时是不可避免的。所以说人不应该使用字母数学不是这样真实的。如果是这样，一个saner的决定是包括三种类型 char ， ubyte ， sbyte 。

More than so, in ANSI C (before C99), the only byte-sized type is char, so using char for math is sometimes inevitable. So saying "one should never use char for math" is not so true. If that was the case, a saner decision was to include three types "char,ubyte,sbyte".

这是有原因的，还是只是一些奇怪的向后兼容性getcha，但普通的）编译器被定义为标准兼容？

Is there a reason for that, or is it just some weird backwards-compatibility gotcha, in order to allow bad (but common) compilers to be defined as standard compatible?

推荐答案

Plainchar具有未指定的签名，允许编译器选择表示对于目标体系结构更有效：在一些体系结构上，将一个字节的值扩展到int的大小需要更少的操作（因此使得纯char是无符号的），而在其他体系结构上，指令集使得符号扩展更自然，和纯char实现签名。

"Plain" char having unspecified signed-ness allows compilers to select whichever representation is more efficient for the target architecture: on some architectures, zero extending a one-byte value to the size of "int" requires less operations (thus making plain char 'unsigned'), while on others the instruction set makes sign-extending more natural, and plain char gets implemented as signed.

这篇关于为什么char的符号在C中没有定义？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！