從 sockaddr_in* 到 sockaddr* 的類型轉換是否違反了“嚴格的別名規則”？

Question

以下類型從sockaddr_in * 轉換為sockaddr * 是否違反“嚴格別名規則”？

來自“Beej 網絡編程指南”（版本 2.3.23）的示例代碼片段。 類型轉換發生在最后一行。

...
#include <arpa/inet.h>
#define MYPORT 3490
main()
{
int sockfd;
struct sockaddr_in my_addr;
sockfd = socket(PF_INET, SOCK_STREAM, 0); 
my_addr.sin_family = AF_INET; 
my_addr.sin_port = htons(MYPORT); 
my_addr.sin_addr.s_addr = inet_addr("10.12.110.57");
memset(&(my_addr.sin_zero), ’\0’, 8); 
bind(sockfd, (struct sockaddr *)&my_addr, sizeof(struct sockaddr));

在這里，為方便起見，我將這些結構定義包括在內：

struct sockaddr {
    unsigned short    sa_family;    // address family, AF_xxx
    char              sa_data[14];  // 14 bytes of protocol address
};


// IPv4 AF_INET sockets:

struct sockaddr_in {
    short            sin_family;   // e.g. AF_INET, AF_INET6
    unsigned short   sin_port;     // e.g. htons(3490)
    struct in_addr   sin_addr;     // see struct in_addr, below
    char             sin_zero[8];  // zero this if you want to
};

struct in_addr {
    unsigned long s_addr;          // load with inet_pton()
};

Answer 1

許多 UNIX 網絡基礎都是建立在這些創造性的“濫用”結構之上的。 這會使在非 C 代碼中使用這些函數和結構變得相當困難，因為許多語言（如 C++）默認禁止此類任意重鑄操作。

在 C++ 中，您需要處理這樣一個事實，是的，從技術上講，這些都不是有效的轉換，但 UNIX 網絡規范已經存在了幾十年並且是一種眾所周知的商品。 無論編譯器堅持什么，您都可以對什么是有效的轉換，什么不是有效的轉換做出合理的假設。

與往常一樣，您需要小心行事，尤其是在進行此類演員時。