这种联合的使用是否严格符合？

Question

给定代码：

struct s1 {unsigned short x;};
struct s2 {unsigned short x;};
union s1s2 { struct s1 v1; struct s2 v2; };

static int read_s1x(struct s1 *p) { return p->x; }
static void write_s2x(struct s2 *p, int v) { p->x=v;}

int test(union s1s2 *p1, union s1s2 *p2, union s1s2 *p3)
{
  if (read_s1x(&p1->v1))
  {
    unsigned short temp;
    temp = p3->v1.x;
    p3->v2.x = temp;
    write_s2x(&p2->v2,1234);
    temp = p3->v2.x;
    p3->v1.x = temp;
  }
  return read_s1x(&p1->v1);
}
int test2(int x)
{
  union s1s2 q[2];
  q->v1.x = 4321;
  return test(q,q+x,q+x);
}
#include <stdio.h>
int main(void)
{
  printf("%d\n",test2(0));
}

整个程序中存在一个联合对象--q。其活动成员设置为v1，然后设置为v2，然后再次设置为v1。代码仅在q.v1 或结果指针上使用地址运算符，当该成员处于活动状态时，同样q.v2。由于p1、p2和p3都是同一类型，所以使用p3->v1访问p1->v1，使用p3->v2访问p2->v2应该是完全合法的。

我没有看到任何可以证明编译器无法输出 1234 的理由，但是包括 clang 和 gcc 在内的许多编译器会生成输出 4321 的代码。我认为正在发生的事情是他们认为 p3 上的操作实际上不会更改内存中任何位的内容，它们可以完全被忽略，但我在标准中没有看到任何可以证明忽略p3 用于将数据从p1->v1 复制到p2->v2 和反之亦然。

标准中是否有任何内容可以证明这种行为是合理的，或者编译器根本不遵循它？

Answer 1

我没有阅读标准，但是在严格混叠模式下使用指针（即使用-fstrict-alising）是危险的。见gcc online doc：

特别注意这样的代码：

union a_union {
  int i;
  double d;
};

int f() {
  union a_union t;
  t.d = 3.0;
  return t.i;
}

从不同的工会成员而不是最近写入的成员（称为type-punning）阅读的做法很常见。即使使用-fstrict-aliasing，也允许使用类型双关语，前提是通过联合类型访问内存。因此，上面的代码按预期工作。请参阅结构联合枚举和位域实现。但是，此代码可能不会：

int f() {
   union a_union t;
   int* ip;
   t.d = 3.0;
   ip = &t.i;
   return *ip;
}

同样，通过获取地址、转换结果指针和取消引用结果的访问具有未定义的行为，即使转换使用联合类型，例如：

int f() {
  double d = 3.0;
  return ((union a_union *) &d)->i;
}

-fstrict-aliasing 选项在 -O2、-O3、-Os 级别启用。

在第二个例子中找到类似的东西吧？

Answer 2

对于标准的严格解释，此代码可能不符合。让我们重点关注著名的§6.5p7的文本：

一个对象的存储值只能由具有以下之一的左值表达式访问 以下类型：
— 与对象的有效类型兼容的类型，
— 与对象的有效类型兼容的类型的限定版本，
— 对应于有效类型的有符号或无符号类型 对象,
— 一种类型，它是有符号或无符号类型，对应于 对象的有效类型，
— 一种聚合或联合类型，其中包含上述类型之一 成员（递归地包括子聚合或包含联合的成员），或
— 一种字符类型。

（强调我的）

您的函数 read_s1x() 和 write_s2x() 与我在上面标记的粗体在您的整个代码的上下文中执行了相反。仅凭这一段，您就可以断定这是不允许的：指向union s1s2 的指针将被允许将指向struct s1 的指针作为别名，但反之则不行。

当然，这种解释意味着如果您在test() 中手动“内联”这些函数，则代码必须按预期工作。对于i686-w64-mingw32，gcc 6.2 确实是这种情况。

---

添加两个支持上述严格解释的论点：

• 虽然总是允许使用char * 为任何指针起别名，但字符数组不能使用任何其他类型的别名。

• 考虑到（此处不相关）§6.5.2.3p6：

  一个特殊的保证是为了简化联合的使用：如果联合包含 几个结构共享一个共同的初始序列（见下文），如果联合 对象当前包含这些结构之一，允许检查常见的 其中任何一个的初始部分在声明联合的完整类型的任何地方 可见。

  （再次强调我的）——典型的解释是 可见 直接在相关函数的范围内，而不是“在翻译单元的某个地方”......所以这个保证不'不包括一个函数，该函数接受一个指向 structs 之一的指针，它是 union 的成员。

Answer 3

这与符合或不符合无关 - 它是优化“陷阱”之一。您的所有数据结构都已优化，并且您将相同的指针传递给优化的数据，因此执行树被简化为值的简单 printf。

  sub rsp, 8
  mov esi, 4321
  mov edi, OFFSET FLAT:.LC0
  xor eax, eax
  call printf
  xor eax, eax
  add rsp, 8
  ret

要更改它，您需要使此“转移”功能易于产生副作用并强制执行实际分配。它将强制优化器不减少执行树中的那些节点：

int test(union s1s2 *p1, union s1s2 *p2, volatile union s1s2 *p3)
/* ....*/

main:
  sub rsp, 8
  mov esi, 1234
  mov edi, OFFSET FLAT:.LC0
  xor eax, eax
  call printf
  xor eax, eax
  add rsp, 8
  ret

这是一个非常简单的测试，只是人为地让它变得更复杂了。

Answer 4

我相信你的代码是合规的，GCC和Clang的-fstrict-aliasing模式存在缺陷。

我找不到 C 标准的正确部分，但是当我在 C++ 模式下编译你的代码时也会出现同样的问题，我确实找到了 C++ 标准的相关段落。

在 C++ 标准中，[class.union]/5 定义了在联合访问表达式上使用运算符 = 时会发生什么。 C++ 标准规定，当内置运算符= 的成员访问表达式中涉及联合时，联合的活动成员将更改为表达式中涉及的成员（如果类型具有普通构造函数，但因为这是 C 代码，它确实有一个简单的构造函数）。

注意write_s2x不能更改联合的活动成员，因为联合不涉及赋值表达式。您的代码不会假设会发生这种情况，所以没关系。

即使我使用位置 new 来显式更改哪个联合成员处于活动状态，这应该是对编译器的一个提示，即活动成员已更改，GCC 仍然会生成输出 4321 的代码。

这看起来像 GCC 和 Clang 的错误，假设活动联合成员的切换不能在这里发生，因为它们无法识别 p1、p2 和 p3 都指向同一个对象的可能性。

GCC 和 Clang（以及几乎所有其他编译器）支持对 C/C++ 的扩展，您可以在其中读取联合的非活动成员（得到任何潜在的垃圾值），但前提是您在涉及联合的成员访问表达式。 如果 v1 不是活动成员，read_s1x 将不会在此实现特定规则下定义为行为，因为联合不在成员访问表达式中。但是因为v1 是活跃成员，所以这无关紧要。

这是一个复杂的案例，我希望我的分析是正确的，作为一个不是编译器维护者或委员会成员的人。