2 回答

• 15

  我已经通过迷宫找到了解决这个问题的方法，我想我已经对它进行了非常全面的总结 . 我发布这个作为答案，因为它似乎解释了C语句的（IMO非常误导）意图和C不继承它的事实 . 如果我发现进一步的支持材料或情况发生变化，这将随着时间的推移而演变 .

  这是我第一次尝试总结一个非常复杂的情况，即使对于许多语言架构师来说这似乎也是不明确的，所以我欢迎有关如何改进这个答案的澄清/建议 - 或者只是一个更好的答案，如果有人有 .

  最后，一些具体的评论

  通过模糊相关的线程，我找到了@tab的以下答案 - 非常感谢所包含的链接（如果不是结论性的话）GCC和工作组缺陷报告：answer by tab on StackOverflow

  GCC链接包含一些有趣的讨论，并揭示了委员会和编制者的一部分相当大的混淆和相互矛盾的解释供应商 - 围绕 union 成员 struct 的主题，在C和C中产生冲突和别名 .

  最后，我们链接到主事件 - 另一个BugZilla线程，Bug 65892，包含 extremely 有用的讨论 . 特别是，我们找到了两个关键文件中的第一个：

  C99中添加行的原点

  C proposal N685是有关 union 类型声明可见性的已添加子句的来源 . 通过一些声称（见GCC线程＃2）对"common initial sequence"津贴的完全误解，N685确实是 intended to allow relaxation of aliasing rules for "common initial sequence" structs within a TU aware of some union containing instances of said struct types ，正如我们从这句话中看到的那样：

  建议的解决方案是要求如果可以通过公共初始序列（如上所述）使用别名，则可以看到联合声明 . 因此，如果需要，以下TU提供这种别名：

  union utag {
      struct tag1 { int m1; double d2; } st1;
      struct tag2 { int m1; char c2; } st2;
  };
  
  int similar_func(struct tag1 *pst2, struct tag2 *pst3) {
       pst2->m1 = 2;
       pst3->m1 = 0;   /* might be an alias for pst2->m1 */
       return pst2->m1;
  }
  

  根据海湾合作委员会的讨论和下面的评论，例如@ ecatmur，这个提议 - 似乎要求推测性地允许任何 struct 类型的别名，在某些 union 中有一些实例可见到这个TU - seems to have received great derision and rarely been implemented .

  显而易见的是，如果没有完全削弱许多优化措施来满足对附加条款的这种解释是多么困难 - 几乎没有什么好处，因为很少有编码人员想要这种保证，而那些做的人只能打开 fno-strict-aliasing （IMO表示更大的问题） . 如果实施的话，这个限额更有可能让人们 grab 并与其他声明 union 进行虚假交互，而不是有用 .

  从C中省略该行

  继此之后以及我在其他地方发表的评论中，@Potatoswatter in this answer here on SO指出：

  可见部分故意从C中省略，因为它被广泛认为是荒谬和无法实现的 .

  换句话说， it looks like C++ deliberately avoided adopting this added clause, likely due to its widely pereceived absurdity. 在询问"on the record"引用时，Potatoswatter提供了有关线程参与者的以下关键信息：

  那次讨论中的人基本上都是“记录在案” . Andrew Pinski是一个铁杆GCC后端人 . Martin Sebor是一名活跃的C委员会成员 . Jonathan Wakely是一名活跃的C委员会成员和语言/图书馆实施者 . 该页面比我能写的任何内容都更具权威性，清晰性和完整性 .

  Potatoswatter在上面链接的相同SO线程中得出结论，C故意排除了这一行，没有对指向公共初始序列的指针进行特殊处理（或者，最好是实现定义的处理） . 他们的待遇是否将在未来具体确定，与其他任何指针相比，还有待观察;与我下面关于C的最后一节相比 . 目前，它不是（而且，IMO，这是好的） .

  这对C和实际C实现意味着什么？

  因此，使用来自N685的邪恶线...'抛开'... we'重新回到假设指向公共初始序列的指针在别名方面并不特别 . 仍然 . 值得确认的是，如果没有它，C中的这一段意味着什么 . 好吧，上面的第二个GCC线程链接到另一个gem：

  C++ defect 1719 . 此提案已达到 DRWP 状态："A DR issue whose resolution is reflected in the current Working Paper. The Working Paper is a draft for a future version of the Standard" - cite . 这是在C 14之后或者至少在我在这里的最终草案之后（N3797） - 并提出了 significant, and in my opinion illuminating, rewrite of this paragraph's wording ，如下所示 . 我正在强调我认为是重要的变化，{这些评论}是我的：

  在具有活动成员的标准布局联合中{“active”表示结构类型T1的联合实例，而不仅仅是类型}（9.5 [class.union]），允许读取{以前“检查”}非结构结构类型T2的另一个联合成员的静态数据成员m提供m是T1和T2的公共初始序列的一部分 . [注意：通过非易失性glvalue读取volatile对象具有未定义的行为（7.1.6.1 [dcl.type.cv]） . - 尾注]

  这似乎澄清了旧措辞的含义：对我而言，它表示任何特别允许 'punning' among union member structs with common initial sequences must be done via an instance of the parent union - 而不是基于 structs 的类型（例如指向它们的指针传递给某个函数） . 这个措辞似乎排除了任何其他解释，即N685 . 我会说，C会采取这种做法 . 嘿，说到哪，见下文！

  结果是 - 正如@ecatmur和GCC门票所证明的那样 - 这留下了 such union member structs by definition in C++, and practically in C, subject to the same strict aliasing rules as any other 2 officially unrelated pointers. 能够读取非活动的共同初始序列 union 成员 struct 的明确保证现在更加明确，不包括模糊和难以想象的单调乏味 - 执行"visibility" asN685尝试用C语言 . 根据这个定义，主编译器的行为与C一样 . 至于C？

  C中的这条线的可能反转/ C中的澄清

  同样非常值得注意的是，C委员会成员Martin Sebor也希望用这种优秀的语言来解决这个问题：

  Martin Sebor 2015-04-27 14:57:16 UTC如果你们中的一个人可以用它来解释这个问题，我愿意写一篇论文并将其提交给WG14，并要求更改标准 . Martin Sebor 2015-05-13 16:02:41 UTC我上周有机会与Clark Nelson讨论这个问题 . Clark过去曾致力于改进C规范的混叠部分，例如在N1520（http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1520.htm） . 他同意，就像N1520中指出的问题一样，这也是一个值得WG14重新审视和修复的突出问题 . “

  Potatoswatter鼓舞人心地总结道：

  C和C委员会（通过马丁和克拉克）将试图找到共识并敲定措辞，以便标准最终可以说出它意味着什么 .

  我们只能希望！

  再次，欢迎所有进一步的想法 .

  回复于 2024-05-01T02:18:50+08:00
• 6

  我怀疑这意味着不仅可以通过联合类型，而且可以在联合之外访问这些公共部分 . 也就是说，假设我们有这个：

  union u {
    struct s1 m1;
    struct s2 m2;
  };
  

  现在假设在某个函数中我们有一个 struct s1 *p1 指针，我们知道这个指针是从这种联合的 m1 成员中解除的 . 我们可以将它转换为 struct s2 * 指针，并仍然可以访问与 struct s1 共有的成员 . 但在范围的某处，必须显示 union u 的声明 . 它必须是完整的声明，它通知编译器成员是 struct s1 和 struct s2 .

  可能的意图是，如果范围中存在这样的类型，则编译器知道 struct s1 和 struct s2 是别名，因此怀疑通过 struct s1 * 指针的访问真正访问 struct s2 ，反之亦然 .

  如果没有任何可见的联合类型以这种方式连接这些类型，就没有这样的知识;可以应用严格别名 .

  由于C中没有措辞，那么为了利用该语言中的“共同初始成员放松”规则，您必须通过联合类型路由访问，如通常所做的那样：

  union u *ptr_any;
  // ...
  ptr_any->m1.common_initial_member = 42;
  fun(ptr_any->m2.common_initial_member);  // pass 42 to fun
  

  回复于 2024-05-01T02:18:50+08:00