是否通过 C99 中未指定的联合进行类型双关，并且它是否已在 C11 中指定？

Question

Stack Overflow 问题Getting the IEEE Single-precision bits for a float 的一些答案建议使用union 结构进行类型双关语（例如：将float 的位转换为uint32_t）：

union {
    float f;
    uint32_t u;
} un;
un.f = your_float;
uint32_t target = un.u;

但是，根据 C99 标准（至少是草案 n1124），工会的 uint32_t 成员的值似乎未指定，其中第 6.2.6.1.7 节规定：

当一个值存储在联合类型对象的成员中时，对象表示中与该成员不对应但与其他成员对应的字节采用未指定的值。

C11 n1570 草案的至少一个脚注似乎暗示这不再是这种情况（参见 6.5.2.3 中的脚注 95）：

如果用于读取联合对象内容的成员与上次用于读取的成员不同 在对象中存储一个值，该值的对象表示的适当部分被重新解释 作为 6.2.6 中描述的新类型中的对象表示（有时称为“类型 双关语''）。这可能是一个陷阱表示。

但是，C99 草案中的第 6.2.6.1.7 节的文本与 C11 草案中的相同。

这种行为在 C99 下实际上是未指定的吗？是否已在 C11 中指定？我意识到大多数编译器似乎都支持这一点，但如果知道它是在标准中指定的，还是只是一个非常常见的扩展，那就太好了。

Answer 1

但是，这似乎违反了 C99 标准（至少是 n1124 草案），其中第 6.2.6.1.7 节规定了一些内容。这种行为在 C99 下实际上是未指定的吗？

不，你很好。

当一个值存储在联合类型对象的成员中时，对象表示中与该成员不对应但与其他成员对应的字节采用未指定的值。

这适用于不同大小的数据块。即，如果您有：

union u
{
    float f;
    double d;
};

如果你给 f 赋值，它会改变 d 的低 4 字节，但高 4 字节会处于不确定状态。

联合主要用于类型双关语。

Answer 2

原始的 C99 规范未指定此内容。

对 C99（我认为是 TR2）的一项技术勘误添加了脚注 82 以纠正这一疏忽：

如果用于访问联合对象内容的成员与上次用于在对象中存储值的成员不同，则将值的对象表示的适当部分重新解释为对象表示中的对象表示6.2.6 中描述的新类型（有时称为“类型双关语”的过程）。这可能是一个陷阱表示。

该脚注保留在 C11 标准中（它是 C11 中的脚注 95）。

Answer 3

使用 union 的类型双关语的行为从 C89 更改为 C99。 C99 中的行为与 C11 相同。

正如Wug 在他的回答中指出的那样，C99 / C11 中允许使用双关语。当联合成员的大小不同时，会读取可能是陷阱的未指定值。

脚注是 C99 在 Clive D.W. 之后添加的。羽Defect Report #257：

最后，从 C90 到 C99 的变化之一是取消了当最后一个商店指向不同的商店时访问联合的一个成员的任何限制。 基本原理是，该行为将随后取决于值的表示。由于这一点经常被误解，因此可能值得在标准中明确说明。

[...]

为了解决关于“类型双关语”的问题，在 6.5.2.3#3 中的“命名成员”一词上附加一个新的脚注 78a： 78a 如果用于访问联合对象内容的成员与上次用于在对象中存储值的成员不同，则将值的对象表示的适当部分重新解释为新类型中的对象表示如 6.2.6 中所述（有时称为“类型双关语”的过程）。这可能是一个陷阱表示。

克莱夫 D.W. 的措辞Feather 在 C 委员会对Defect Report #283 的回答中被接受为技术勘误。

Answer 4

这一直是“不确定的”。正如其他人所指出的，通过技术更正向 C99 添加了脚注。内容如下：

如果用于访问联合对象内容的成员与上次用于在对象中存储值的成员不同，则将值的对象表示的适当部分重新解释为对象表示中的对象表示6.2.6 中描述的新类型（有时称为“类型双关语”的过程）。这可能是一个陷阱表示。

但是，前言中的脚注是非规范性的：

附件 D 和 F 构成本标准的规范性部分；附件 A、B、C、E、G、H、I、J、参​​考书目和索引仅供参考。根据 ISO/IEC 指令的第 3 部分，本前言、引言、注释、脚注和示例也仅供参考。

也就是说，脚注不能禁止行为；他们只应澄清现有案文。这是一个不受欢迎的观点，但上面引用的脚注在这方面实际上是失败的——规范文本中没有禁止这种行为。确实有矛盾的部分，比如6.7.2.1：

...任何时候最多可以将其中一个成员的值存储在联合对象中

结合 6.5.2.3（关于使用“.”操作符访问联合成员）：

值是命名成员的值

即如果只能存储一个成员的值，则另一个成员的值不存在。这强烈暗示通过联合的类型双关应该不是可能的；成员访问产生一个不存在的值。 C11 文档中仍然存在相同的文本。

但是，很明显，添加脚注的目的是允许类型双关；只是委员会似乎违反了不包含规范性文本的脚注规则。要接受脚注，您真的必须忽略脚注不是规范性的部分，或者试图弄清楚如何以支持脚注结论的方式解释规范性文本（我已经尝试过，并且失败，做）。

关于批准脚注，我们能做的最好的事情是对从 6.2.5 起将联合定义为一组“重叠对象”做出一些假设：

联合类型描述了一组重叠的非空成员对象，每个对象都有一个可选的指定名称和可能不同的类型

不幸的是，没有详细说明“重叠”的含义。一个对象被定义为（3.14）“执行环境中的数据存储区域，其内容可以表示值”（即相同的存储区域可以由两个或多个distinct 对象由上面的“重叠对象”定义暗示，即对象具有与其存储区域分开的标识）。合理的假设似乎是（特定联合实例的）联合成员使用相同的存储区域。

即使我们忽略 6.7.2.1/6.5.2.3 并允许（如脚注所示）读取任何联合成员返回将由相应存储区域的内容表示的值 - 因此将允许类型双关——6.5 中一直存在问题的严格别名规则不允许（除了某些小例外）访问对象，而不是按其类型。由于“访问”是（3.1）“读取或修改对象的值”，并且由于修改一组重叠对象中的一个必然会修改其他对象，因此严格混叠规则可以写入工会成员可能会违反（无论是否通过另一个成员读取）。

例如，按照标准的措辞，以下内容是非法的：

union {
   int a;
   float b;
} u;

u.a = 0; // modifies a float object by an lvalue of type int
int *pa = &u.a;
*pa = 1; // also modifies a float object, without union lvalue involved

（具体来说，注释的两行违反了严格的别名规则）。

严格来说，脚注涉及一个单独的问题，即阅读不活跃的工会成员；然而，严格别名规则与上面提到的其他部分一起严重限制了它的适用性，特别是意味着它通常不允许类型双关语（但仅适用于特定的类型组合）。

令人沮丧的是，负责制定标准的委员会似乎打算通过联合来实现类型双关语，但似乎并不担心标准文本仍然不允许它。

还值得注意的是，（编译器供应商）的共识理解似乎是允许通过联合进行类型双关，但“必须通过联合类型访问”（例如上面示例中的第一个注释行，但是不是第二个）。有点不清楚这是否应该同时适用于读取和写入访问，并且标准文本绝不支持（忽略脚注）。

总结：虽然通过联合的类型双关语在很大程度上被接受是合法的（大多数人认为只有在“通过联合类型”完成访问时才允许，可以这么说），标准的措辞禁止它在除了某些琐碎的案例之外的所有情况。

你引用的部分：

当一个值存储在联合类型对象的成员中时，对象表示中与该成员不对应但与其他成员对应的字节采用未指定的值。

...不过，必须仔细阅读。 “对象表示的字节不对应于该成员”是指超出成员大小的字节，这本身不是类型双关的问题（除非你不能假设写作对工会成员来说，任何较大成员的“额外”部分都不会受到影响）。