关于 C 中联合的问题 - 存储为一种类型并读取为另一种类型 - 它是实现定义的吗？

Question

我正在阅读 K&R 中关于 C 中的 union 的内容，据我了解，union 中的单个变量可以保存多种类型中的任何一种，如果某些内容存储为一种类型并提取为另一种类型，则结果纯粹是实现定义的。

现在请检查此代码片段：

#include<stdio.h>

int main(void)
{
  union a
  {
     int i;
     char ch[2];
  };

  union a u;
  u.ch[0] = 3;
  u.ch[1] = 2;

  printf("%d %d %d\n", u.ch[0], u.ch[1], u.i);

  return 0;
}

输出：

3 2 515

这里我在 u.ch 中分配值，但从 u.ch 和 ui 中检索。是否定义了实现？或者我正在做一些非常愚蠢的事情？

我知道对于大多数其他人来说这可能看起来很初学者，但我无法弄清楚该输出背后的原因。

谢谢。

Answer 1

这是未定义的行为。 ui 和 u.ch 位于同一内存地址。因此，写入其中一个并从另一个读取的结果取决于编译器、平台、体系结构，有时甚至取决于编译器的优化级别。因此 ui 的输出可能并不总是 515。

示例

例如，我机器上的 gcc 为 -O0 和 -O2 生成两个不同的答案。

1. 因为我的机器具有 32 位小端架构，使用 -O0 我最终得到两个最低有效字节初始化为 2 和 3，两个最高有效字节未初始化。所以联合体的内存看起来像这样：{3, 2,garbage,garbage}

   因此我得到类似于 3 2 -1216937469 的输出。

2. 使用 -O2，我像您一样得到 3 2 515 的输出，这使得联合内存 {3, 2, 0, 0}< /代码>。发生的情况是，gcc 使用实际值优化了对 printf 的调用，因此汇编输出看起来相当于：

   #include ;
   int main() {
       printf("%d %d %d\n", 3, 2, 515);
       返回0；
   }
   

   可以按照此问题的其他答案中的其他解释获得值 515。本质上，这意味着当gcc优化调用时，它选择了零作为可能未初始化的联合的随机值。

向一名工会成员写入并从另一名工会成员读取通常没有多大意义，但有时它对于使用严格别名编译的程序可能很有用。

Answer 2

这个问题的答案取决于历史背景，因为语言的规范随着时间而变化。而这件事，恰好是受到变化影响的事情。

你说你在读《K&R》。该书的最新版本（截至目前）描述了 C 语言的第一个标准化版本 - C89/90。在该版本的 C 语言中，写入联合体的一个成员并读取另一个成员是未定义的行为。不是实现定义（这是另一回事），而是未定义行为。本例中语言标准的相关部分是 6.5/7。

现在，在 C 发展的后期（应用了技术勘误 3 的语言规范的 C99 版本），使用联合进行类型双关突然变得合法，即编写联合的一个成员，然后读取另一个成员。

请注意，尝试这样做仍然可能导致未定义的行为。如果您读取的值恰好对于您读取的类型无效（所谓的“陷阱表示”），则该行为仍然是未定义的。否则，您读取的值是实现定义的。

您的特定示例对于从 int 到 char[2] 数组的类型双关相对安全。在 C 语言中，将任何对象的内容重新解释为 char 数组始终是合法的（同样，6.5/7）。

然而，反之则不然。将数据写入联合体的 char[2] 数组成员，然后将其作为 int 读取，可能会创建陷阱表示并导致未定义的行为。即使您的 char 数组有足够的长度来覆盖整个 int，也存在潜在的危险。

但在您的具体情况下，如果 int 恰好大于 char[2]，您读取的 int 将覆盖末尾之外的未初始化区域数组的值，这又会导致未定义的行为。

Answer 3

输出背后的原因是，在您的计算机上，整数存储在 little-endian 中格式：首先存储最低有效字节。因此字节序列
[3,2,0,0]表示整数3+2*256=515。

这个结果取决于具体的实现和平台。

Answer 4

此类代码的输出将取决于您的平台和 C 编译器实现。您的输出让我认为您正在小端系统（可能是 x86）上运行此代码。如果您将 515 放入 i 中并在调试器中查看它，您会发现最低位字节将是 3，内存中的下一个字节将是 2，它与您放入 ch 中的内容精确映射。

如果您在大端系统上执行此操作，您（可能）会得到 770（假设 16 位整数）或 50462720（假设 32 位整数）。

Answer 5

它取决于实现，结果可能会在不同的平台/编译器上有所不同，但似乎这就是正在发生的事情：

二进制中的 515 是

1000000011

填充零以使其成为两个字节（假设 16 位 int）：

0000001000000011

这两个字节是：

00000010 and 00000011

这是 2 和 3

希望有人解释为什么它们被颠倒 - 我的猜测是字符没有颠倒，但 int 是小尾数。

分配给联合的内存量等于存储最大成员所需的内存。在本例中，您有一个 int 和一个长度为 2 的 char 数组。假设 int 是 16 位，char 是 8 位，两者都需要相同的空间，因此 union 分配了两个字节。

当您将三个 (00000011) 和两个 (00000010) 分配给 char 数组时，联合状态为 0000001100000010。当您从这个联合中读取 int 时，它会将整个事物转换为整数。假设 LSB 存储在最低地址的 little-endian 表示形式，则 int 读取来自联合的结果将是 0000001000000011，它是 515 的二进制文件。

注意：即使 int 是 32 位，这也成立 - 检查 阿姆农的回答

Answer 6

如果您使用的是 32 位系统，则 int 为 4 个字节，但您只初始化了 2 个字节。访问未初始化的数据是未定义的行为。

假设您使用的是 16 位整数的系统，那么您所做的仍然是实现定义的。如果您的系统是小端，则 u.ch[0] 将对应 ui 的最低有效字节，而 u.ch1 将是最高有效字节。在大端系统上，情况正好相反。此外，C 标准并不强制实现使用 二进制补码 来表示有符号整数值，尽管补码是最常见的。显然，整数的大小也是实现定义的。

提示：如果使用十六进制值，可以更轻松地了解发生的情况。在小端系统上，十六进制结果将为 0x0203。