使用 char * 访问 int 是否可能具有未定义的行为？

Question

以下用于测试字节顺序的代码预计具有实现定义的行为：

int is_little_endian(void) {
    int x = 1;
    char *p = (char*)&x;
    return *p == 1;
}

但它是否可能在故意设计的架构上具有未定义的行为？例如，int 表示的第一个字节，其值为 1（或另一个精心选择的值）是否可以是 char 类型的陷阱值？

如 cmets 中所述，unsigned char 类型不会有此问题，因为它不能有陷阱值，但此问题特别涉及 char 类型。

Answer 1

根据 C 2018 6.2.5 15，char 的行为类似于 signed char 或 unsigned char。假设它是signed char。 6.2.6.2 2 讨论有符号整数类型，包括signed char。在本段的末尾，它说：

这些[符号和幅度、二的补码或一个的补码]中的哪一个适用是实现定义的，正如是否符号位为 1 且所有值位为零（对于前两位）或符号位和所有值位为 1（对于一个补码）的值是陷阱表示或正常值。

因此，这一段允许signed char 有一个陷阱表示。但是，标准中说访问陷阱表示可能具有未定义行为的段落 6.2.6.1 5 明确排除了字符类型：

某些对象表示不需要表示对象类型的值。如果对象的存储值具有这样的表示形式并且由不具有字符类型的左值表达式读取，则行为未定义。如果这种表示是由通过不具有字符类型的左值表达式修改对象的全部或任何部分的副作用产生的，则行为未定义。这种表示称为陷阱表示。

因此，尽管char 可能有陷阱表示，但我们没有理由不能访问它。那么问题来了，如果我们在表达式中使用值会发生什么？如果char 具有陷阱表示，则它不表示值。因此，尝试将其与 *p == 1 中的 1 进行比较似乎没有明确的行为。

对于任何正常的 C 实现，int 中的特定值 1 不会导致 char 中的陷阱表示，因为 1 将位于某个字节的“最右边”（最低值）位中int，并且没有正常的 C 实现将 char 的符号位放在该位置的位中。但是，C 标准显然不禁止这种安排，因此，理论上，值为 1 的int 可能在其一个字节中使用位 00000001 进行编码，并且这些位可能是char 的陷阱表示。

Answer 2

我不认为标准会禁止signed char 使用符号幅度或一个补码格式的实现，并在尝试加载表示“负零”的位模式时陷入困境。它也不要求此类实现必须使char 无符号。可以设计一种架构，您的代码可以在该架构上具有任意行为。不过，还有一些更重要的事情需要注意：

1. 无法保证char 中的位与int 中的位映射顺序相同。如果位没有按顺序映射，代码将不会启动到 UB-land，但结果不会很有意义。

2. 据我所知，每个非人为的符合 C99 的实现都使用二进制补码格式；我认为有人会不这样做是值得怀疑的。

3. 如果实现使 char 成为可表示值少于位模式的类型，那将是愚蠢的。

4. 只要存在一些可以按照标准定义的方式处理的源文本，就可以设计出一种符合标准的实现，该实现几乎可以对任何源文本执行任何操作。

可以设计一个符合符号幅度的实现，其中整数值 1 将具有一个位模式，该模式将编码带符号的 char 值“负零”，并且会在尝试加载它时陷入困境。甚至可以设计一个符合要求的补码实现（在“int”类型上有很多填充位，所有这些在存储值“1”时都被设置）。鉴于人们可以设计一个符合要求的实现，该实现使用 One Program 规则来证明对上述源文本做任何它喜欢的事情，而不管它使用什么整数格式，但是，我认为奇怪的 char 类型的可能性不应该真的放心吧。

注意，顺便说一句，标准没有努力禁止愚蠢的实现；可以通过添加语言来改进它，要求 char 必须是没有陷阱表示的二进制补码类型或无符号类型，并且要么对 signed char 强制要求相同，要么明确表示不需要。如果它识别出不能支持像unsigned long long 这样的类型的实现类别，它也可能会得到改进[这将是 36 位补码系统的主要绊脚石，并且可能是不符合 C99 的原因此类平台存在实现]。

Answer 3

我从标准中找到了一个引用，证明没有对象表示是unsigned char 的陷阱值：

6.2.6.2 整数类型

1 对于 unsigned char 以外的无符号整数类型， 对象的位 表示应分为两组：值位和填充位（需要 不是后者）。如果有 N 个值位，每个位应代表不同的 1 和 2N-1 之间的 2 的幂，因此该类型的物体应能够 使用纯二进制表示表示从 0 到 2N - 1 的值；这应该是 称为值表示。任何填充位的值都是未指定的。53)

前面说unsigned char 不能有任何填充位。

以下脚注说明填充位可用于陷阱表示。

53) 填充位的某些组合可能会产生陷阱表示，例如，如果一个填充 位是奇偶校验位。无论如何，对有效值的算术运算都不会产生陷阱 表示不是作为异常条件（如溢出）的一部分，并且这不会发生 无符号类型。填充位的所有其他组合都是替代对象表示 值位指定的值。

所以我猜答案是 char 不能保证没有任何陷阱值，但 unsigned char 是。