在过去的十年中，C和C ++编译器比
sockaddr设计接口甚至编写C99时要复杂得多。作为其一部分，已理解的“未定义行为”的 目的_已经改变。回顾过去，未定义的行为通常旨在涵盖_硬件_实现之间关于操作语义的分歧。但是如今，最终归功于许多组织希望停止编写FORTRAN并有能力支付编译器工程师来实现这一目标，未定义的行为是编译器用来
_推断代码 的事情。左移是一个很好的例子：C99 6.5.7p3,4（为清楚起见重新排列了一下）读取
结果
E1 << E2是E1左移位E2位置；空位用零填充。如果[E2]的值为负或大于或等于提升的[E1] 的宽度，则行为不确定。
因此，例如，
1u << 33UB在
unsignedint32位宽的平台上。该委员会之所以没有定义，是因为在这种情况下，不同的CPU架构的左移指令执行不同的操作：有些始终产生零，有些减少了类型宽度（x86）的模数，有些减少了模数的位数。
（ARM），并且至少有一种历史上常见的体系结构会陷入陷阱（我不知道是哪一种，但这就是为什么它是未定义且未指定的原因）。但是现在，如果你写
unsigned int left_shift(unsigned int x, unsigned int y){ return x << y; }在具有32位的平台上
unsigned int，知道上述UB规则的编译器将 在 调用该函数时
推断出
y必须具有介于0到32之间的值。它将把该范围输入到过程间分析中，并使用它来执行诸如在调用方中删除不必要的范围检查之类的操作。如果程序员有理由认为它们
不是 不必要的，那么，现在您开始了解为什么这个主题如此蠕虫。
有关针对未定义行为目的进行的更改的更多信息，请参阅LLVM人们关于该主题的三部分文章（1
2
3）。
现在您已经了解了，我实际上可以回答您的问题。
在消除了一些不相关的并发症之后
struct sockaddr，这些是
struct sockaddr_in，和的定义
structsockaddr_storage：
struct sockaddr { uint16_t sa_family;};struct sockaddr_in { uint16_t sin_family; uint16_t sin_port; uint32_t sin_addr;};struct sockaddr_storage { uint16_t ss_family; char __ss_storage[128 - (sizeof(uint16_t) + sizeof(unsigned long))]; unsigned long int __ss_force_alignment;};这是穷人的子类。它是C语言中的一个普遍用法。您定义了一组结构，它们都具有相同的初始字段，这是一个代码号，用于告诉您实际上已通过了哪种结构。回想过去，每个人都希望，如果您分配并填写了一个
structsockaddr_in，向上转换为
struct sockaddr，并将其传递给例如
connect，实现
connect可以
structsockaddr安全地取消对指针的引用以检索该
sa_family字段，得知它正在查看a
sockaddr_in并将其抛回，然后继续。C标准一直说取消引用
struct sockaddr指针会触发未定义的行为-自C89以来，这些规则未更改-
但每个人都希望 在这种情况下 这样做是安全的 __因为无论您使用的是哪种结构，它都是相同的“加载16位”指令。
这就是POSIX和Windows文档谈论对齐的原因。早在1990年代编写这些规范的人就认为， 实际上
可能造成麻烦的主要方式是，如果您结束发布未对齐的内存访问。
但是该标准的文本中没有任何关于加载指令或对齐的内容。它是这样说的（C99§6.5p7+脚注）：
一个对象只能通过具有以下类型之一的左值表达式访问其存储值：73）
- 与对象的有效类型兼容的类型，
- 与对象的有效类型兼容的类型的限定版本，
- 类型是与对象的有效类型相对应的有符号或无符号类型，
- 一种类型，是与对象的有效类型的限定版本相对应的有符号或无符号类型，
- 在其成员（包括递归地，子集合或包含的联盟的成员）中包括上述类型之一的集合或联合类型，或
- 字符类型。
73）此列表的目的是指定对象可能会别名也可能不会别名的那些情况。
struct类型仅与自身“兼容”，声明的变量的“有效类型”是其声明的类型。所以您显示的代码…
struct sockaddr_storage addrStruct;case AF_INET: { struct sockaddr_in * tmp = (struct sockaddr_in *)&addrStruct; tmp->sin_family = AF_INET; tmp->sin_port = htons(port); inet_pton(AF_INET, addr, tmp->sin_addr);}break;…具有未定义的行为， 即使 幼稚的代码生成将按预期运行，编译器也可以从中进行推断。现代编译器可能由此推断出，
case AF_INET
永远无法执行 。它将整个块删除为死代码，并随之而来。
那么，您如何
sockaddr安全地工作呢？最简单的答案是“随便使用
getaddrinfo和”
getnameinfo。他们为您解决了这个问题。
但是，也许你需要工作，一个地址族，比如
AF_UNIX，即
getaddrinfo不处理。在大多数情况下，您只需声明地址族类型正确的变量，然后 _仅_在调用带有
struct sockaddr *
int connect_to_unix_socket(const char *path, int type){ struct sockaddr_un sun; size_t plen = strlen(path); if (plen >= sizeof(sun.sun_path)) { errno = ENAMETOOLONG; return -1; } sun.sun_family = AF_UNIX; memcpy(sun.sun_path, path, plen+1); int sock = socket(AF_UNIX, type, 0); if (sock == -1) return -1; if (connect(sock, (struct sockaddr *)&sun, offsetof(struct sockaddr_un, sun_path) + plen)) { int save_errno = errno; close(sock); errno = save_errno; return -1; } return sock;}该 实施 的
connect有通过一些跳铁圈，使这个安全的，但是这不是你的问题。
魂斗罗对方的回答，有 是 一个情况下，你可能想要使用
sockaddr_storage;与
getpeername和一起
getnameinfo在需要同时处理IPv4和IPv6地址的服务器中。这是一种知道要分配多少缓冲区的简便方法。
#ifndef NI_IDN#define NI_IDN 0#endifchar *get_peer_hostname(int sock){ char addrbuf[sizeof(struct sockaddr_storage)]; socklen_t addrlen = sizeof addrbuf; if (getpeername(sock, (struct sockaddr *)addrbuf, &addrlen)) return 0; char *peer_hostname = malloc(MAX_HOSTNAME_LEN+1); if (!peer_hostname) return 0; if (getnameinfo((struct sockaddr *)addrbuf, addrlen, peer_hostname, MAX_HOSTNAME_LEN+1, 0, 0, NI_IDN) { free(peer_hostname); return 0; } return peer_hostname;}（我也可能写过
struct sockaddr_storage addrbuf，但是我想强调一点，我实际上不需要
addrbuf直接访问的内容。）
最后要注意的：如果BSD人已经确定sockaddr结构只是一个 小 有点不同......
struct sockaddr { uint16_t sa_family;};struct sockaddr_in { struct sockaddr sin_base; uint16_t sin_port; uint32_t sin_addr;};struct sockaddr_storage { struct sockaddr ss_base; char __ss_storage[128 - (sizeof(uint16_t) + sizeof(unsigned long))]; unsigned long int __ss_force_alignment;};…由于“包含上述类型之一的聚合或联合”规则，上流和下流本来可以很好地定义。如果您想知道如何在新的C代码中处理此问题，请继续。
