在过去的十年中，C和C ++编译器比sockaddr设计接口甚至编写C99时要复杂得多。作为其一部分，已理解的“未定义行为”的 目的_已经改变。回顾过去，未定义的行为通常旨在涵盖_硬件_实现之间关于操作语义的分歧。但是如今，最终归功于许多组织希望停止编写FORTRAN并有能力支付编译器工程师来实现这一目标，未定义的行为是编译器用来
_推断代码 的事情。左移是一个很好的例子：C99 6.5.7p3,4（为清楚起见重新排列了一下）读取

结果E1 << E2是E1左移位E2位置；空位用零填充。如果[ E2]的值为负或大于或等于提升的[ E1] 的宽度，则行为不确定。

因此，例如，1u << 33UB在unsigned int32位宽的平台上。该委员会之所以没有定义，是因为在这种情况下，不同的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，和的定义struct sockaddr_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语言中的一个普遍用法。您定义了一组结构，它们都具有相同的初始字段，这是一个代码号，用于告诉您实际上已通过了哪种结构。回想过去，每个人都希望，如果您分配并填写了一个struct sockaddr_in，向上转换为struct sockaddr，并将其传递给例如connect，实现connect可以struct sockaddr安全地取消对指针的引用以检索该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
#endif
char *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代码中处理此问题，请继续。