普通的`char`可能有陷阱值吗？

Question

自述

甲"陷阱值",或"陷阱表示"类型T,是一个比特组合(底层存储的),其产生的无效的值T.试图解释为无效值的表示将导致未定义的行为.

---

让战斗开始......

另一个问题已经开始了一个激烈的讨论char,以及实现具有陷阱表示的可能性.

问题:

• 能char可能有陷阱值？

---

前面讨论中提到的行情:

在前面的论证中,这些部分是引用最多的部分,它们是否相矛盾？

3.9.1p1 基本类型 [basic.fundamental]

它是实现定义的,是否char可以保持负值.可以显式声明字符signed或unsigned.

甲char,一个signed char,和unsigned char占据存储相同量的并具有相同的对准要求(3.11); 也就是说,它们具有相同的对象表示.对于字符类型,对象表示的所有位都参与值表示.

对于无符号字符类型,值表示的所有可能位模式表示数字.这些要求不适用于其他类型.

在任何特定实现中,普通char对象可以采用与a signed char或unsigned char;实现定义的值相同的值.

3.9p2 类型 [basic.types]

对于平凡可复制类型的任何对象(基类子对象除外),T,无论对象是否包含有效的类型值,构成对象T的基础字节(1.7)都可以复制到数组char或unsigned char.

如果阵列的内容char或unsigned char将被复制回对象,该对象随后应保持其原始值.

Answer 1

标准告诉我们必须:

• char,signed char,unsigned char,大小相同
• sizeof(char)是1
• char至少有8位
• 每一位组合都是有意义和有效的
• char数组被打包(或者表现如果是).

没有太多的摆动空间.

然而,有人建议在某些类型的操作中,例如加载未初始化的内存或转换,因为可能会发生陷阱.

是的,我认为实现可能有陷阱表示,其中陷阱值可能由于某种未定义或未指定的行为而发生,包括评估涉及未指定/未初始化值的表达式.导致陷阱值的实际位模式对于实现是不可见的.

这样的CPU可以具有9位字节,其中编译器和运行时仅可见8位,第9位用于检测未初始化的存储器,并且如果由(非特权的)指令加载则将触发陷阱.