sockaddr_in 和 sockaddr_in6 还在使用 sin_len 和 sin6_len 吗？

Question

所以，基本上标题说明了一切。我一直在将我的 unix socket C 代码移植到 Windows，显然这些结构在 Windows 中没有 sin_len 或 sin6_len。

我在任何地方都使用 sockaddr_storage、sockaddr_in 和 sockaddr_in6 之间的联合，并且只是根据 ss_family 使用正确的成员。套接字库可以根据系列推断大小是有道理的，因此长度字段确实是多余的。

如果我注释掉设置长度字段的代码，一切在 OSX 和 linux 上仍然有效，但这可能只是一种错觉，所以我决定在这里问。不知何故，该变量是否已被弃用？我可以安全地停止使用它，并依靠套接字实现来使用家庭变量吗？

Answer 1

POSIX 规范不需要 sin_len 字段。

以下是Unix Network Programming - Vol 1. The Sockets Networking API, 3rd Edition的相关信息：

3.2 套接字地址结构

当添加对 OSI 协议的支持时，长度成员sin_len是在 4.3BSD-Reno 中添加的（图 1.15）。在此版本之前，第一个成员是sin_family，它在历史上是一个未签名的空头。并非所有供应商都支持套接字地址结构的长度字段，POSIX 规范不要求此成员。

进一步史蒂文提供了该领域背后的动机：

具有长度字段简化了可变长度套接字地址结构的处理。

即使长度字段存在，我们也不需要设置它，也不需要检查它，除非我们正在处理路由套接字（第 18 章）。它在内核中由处理来自各种协议族（例如，路由表代码）的套接字地址结构的例程使用。

将套接字地址结构从进程传递到内核的四个套接字函数bind、connect、sendto 和 sendmsg都通过Berkeley 派生实现中的sockargs函数（TCPv2 的第 452 页）。此函数从进程复制套接字地址结构，并将其sin_len成员显式设置为作为参数传递给这四个函数的结构的大小。将套接字地址结构从内核传递给进程的五个套接字函数accept、recvfrom、recvmsg、getpeername 和getsockname都在返回进程之前设置了sin_len成员。

不幸的是，通常没有简单的编译时测试来确定一个实现是否为其套接字地址结构定义了长度字段......我们将在图 3.4 中看到，如果套接字地址结构具有长度，则 IPv6 实现需要定义SIN6_LEN场地。一些 IPv4 实现基于编译时选项（例如_SOCKADDR_LEN）向应用程序提供套接字地址结构的长度字段。

您需要评估代码中 sin_len 的使用情况。如果只是将其初始化为 0，则可以删除代码。如果您从accept、recvfrom、recvmsg、getpeername 或 getsockname的结果中读取值，不幸的是，您将需要一些特定于平台的编译开关或切换到使用单独的地址长度变量