c - 为什么尽管 C 有严格的别名规则，但仍允许引用具有相似第一成员的结构？

Question

首先，如果这看起来是重复的，我深表歉意，但我无法在其他地方找到这个问题

我正在通读 N1570 ，特别是§6.5¶7，内容如下:

An object shall have its stored value accessed only by an lvalue expression that has one of the following types:
— a type compatible with the effective type of the object,
— a qualified version of a type compatible with the effective type of the object,
— a type that is the signed or unsigned type corresponding to the effective type of the object,
— a type that is the signed or unsigned type corresponding to a qualified version of the effective type of the object,
— an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union), or
— a character type.

这让我想起了我在(类似 BSD 的)套接字编程中看到的一个常见习语，尤其是在 connect() 中。称呼。虽然 connect() 的第二个参数是一个 struct sockaddr *，但我经常看到传递给它的是一个 struct sockaddr_in *，这似乎之所以有效，是因为它们共享相似的初始元素。我的问题是:

这种情况适用于上述规则中详述的哪些意外事件，为什么，或者现在未定义的行为是以前标准的产物？

Answer 1

此行为未由 C 标准定义。

该行为由单一 Unix 规范和/或与您正在使用的软件相关的其他文档定义，尽管部分是隐含的。

“一个对象应的存储值只能由……访问”这样的表述具有误导性。 C 标准不能强制你做任何事情；您没有义务遵守其“应”要求。就 C 标准而言，不遵守其要求的唯一后果是 C 标准未定义行为。这并不禁止其他文档定义行为。

在the netinet/in.h documentation ，我们看到“sockaddr_in 结构用于存储 Internet 协议(protocol)系列的地址。这种类型的值必须转换为 struct sockaddr 才能与本文档中定义的套接字接口(interface)一起使用。”所以文档不仅告诉我们应该，而且必须将 sockaddr_in 转换为 sockaddr。我们必须这样做的事实意味着该软件支持它并且它将起作用。 (请注意，这里的措辞不准确；我们实际上并没有将 sockaddr_in 转换为 sockaddr，而是实际转换了指针，导致 sockaddr_in 对象在内存中被视为 sockaddr。)

因此，为 Unix 实现提供的操作系统、库和开发人员工具隐含地 promise 支持这一点。

这是对 C 语言的扩展:在 C 标准未定义行为的地方，其他文档可能会提供定义，并允许您编写无法单独使用 C 标准编写的软件。 C 标准所说的未定义 行为并不是被禁止的行为，而是可以由其他规范填充的空白区域。