C11 中的联合和严格别名

Question

假设我有这样的工会

union buffer {
  struct { T* data; int count; int capacity; };
  struct { void* data; int count; int  capacity; } __type_erased;
};

如果我在 C11 别名规则下混合读取/写入匿名结构成员和 __type_erased 成员，我会遇到麻烦吗？

更具体地说，我对独立访问组件（例如通过不同的指针）时发生的行为感兴趣。举例说明：

grow_buffer(&buffer.__type_erased);
buffer.data[buffer.count] = ...

我已经阅读了我能找到的所有相关问题，但我仍然不是 100% 清楚这一点，因为有些人似乎认为这种行为是未定义的，而另一些人则认为这是合法的。此外，我发现的信息是 C++、C99、C11 等规则的混合体，很难消化。在这里，我对 C11 强制执行并由流行编译器（Clang、GCC）展示的行为非常感兴趣

编辑：更多信息

我现在已经对多个编译器进行了一些实验，并决定分享我的发现，以防有人遇到类似问题。我的问题的背景是我试图用纯 C 编写一个用户友好的高性能通用动态数组实现。这个想法是数组操作是使用宏和重型操作（如增长数组）进行的使用别名类型擦除的模板结构执行。例如，我可以有这样的宏：

#define ALLOC_ONE(A)\
    (_array_ensure_size(&A.__type_erased, A.count+1), A.count++)

必要时增加数组并返回新分配项的索引。规范（6.5.2.3）规定允许通过不同的联合成员访问同一位置。我对此的解释是，虽然 _array_ensure_size() 不知道联合类型，但编译器应该知道成员 __type_erased 可能会因副作用而发生变异。也就是说，我认为这应该可行。然而，这似乎是一个灰色地带（老实说，规范并不清楚什么构成了成员访问）。苹果最新的 Clang (clang-800.0.33.1) 没有问题。代码在没有警告的情况下编译并按预期运行。但是，当使用 GCC 5.3.0 编译时，代码会因段错误而崩溃。事实上，我强烈怀疑 GCC 的行为是一个错误——我尝试通过删除可变指针 ref 并采用清晰的函数式样式来明确联合成员突变，例如：

#define ALLOC_ONE(A) \
   (A.__type_erased = _array_ensure_size(A.__type_erased, A.count+1),\
    A.count++)

正如预期的那样，这再次与 Clang 一起工作，但再次使 GCC 崩溃。我的结论是，使用联合的高级类型操作是一个应该谨慎行事的灰色地带。

Answer 1

C11 标准规定如下：

6.5.2.3 结构和联合成员

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

因此，从 C11 中联合字段读/写的角度来看，这是正确的。但是严格别名是基于类型的分析，所以它的幼稚实现可以说这些读/写操作是独立的。据我了解，现代 gcc 可以检测带有联合字段的情况并避免此类错误。

另外你应该记住，在某些情况下，指向联合成员的指针是无效的：

以下不是有效片段（因为联合类型不是 在函数 f) 中可见：

struct t1 { int m; };
struct t2 { int m; };
int f(struct t1 *p1, struct t2 *p2)
{
  if (p1->m < 0)
  p2->m = -p2->m;
  return p1->m;
}
int g()
{
  union {
    struct t1 s1;
    struct t2 s2;
  } u;
  /* ... */
  return f(&u.s1, &u.s2);
}

在我看来，使用工会在不同的成员中读/写是危险的，最好避免它。