Question

Specifically sin_addr seems to be located on different memory locations for IPv4 and IPv6 socket addressed. This results in weirdness:

#include <stdio.h>                                                                               
#include <netinet/in.h>                                                                          

int main(int argc, char ** argv) {                                                               
  struct sockaddr_in sa;                                                                         
  printf("sin_addr in sockaddr_in  = %p\n", &sa.sin_addr);                                       
  printf("sin_addr in sockaddr_in6 = %p\n", &((struct sockaddr_in6*)&sa)->sin6_addr);            
};

Output:

sin_addr in sockaddr_in  = 0x7fffa26102b4
sin_addr in sockaddr_in6 = 0x7fffa26102b8

Why aren’t these 2 values the same ?

Since this is pointing to the same data (the address to connect to), this should be located at the same address. Otherwise, how are you supposed to call inet_ntop with a sockaddr_in that you don’t know is IPv4 or IPv6 ?

Answer 1

Why aren’t these 2 values the same ?

sockaddr_in and sockaddr_in6 are different structs used for different address families (IPv4 and IPv6, respectively). They are not required to be compatible with each other in any way except one – the first field must be a 16-bit integer to hold the address family. sockaddr_in always has that field set to AF_INET, and sockaddr_in6 always has that field set to AF_INET6. By standardizing the family field in this way, any sockaddr-based API can access that field and know how to interpret the rest of the struct data as needed. That is also why sockaddr-based APIs usually also have an int size value as input/output as well, since sockaddr_in and sockaddr_in6 are different byte sizes, so APIs need to be able to validate the size of any buffers you pass around.

Since this is pointing to the same data (the address to connect to), this should be located at the same address.

No, it should not. The location of the address field within the struct is specific to the type of address family the struct belongs to. There is no requirement that sockaddr_in and sockaddr_in6 should store their addresses at the exact same offset.

Otherwise, how are you supposed to call inet_ntop with a sockaddr_in that you don’t know is IPv4 or IPv6 ?

sockaddr_in can only be used with IPv4 and nothing else, and sockaddr_in6 can only be used with IPv6 and nothing else. If you have a sockaddr_in then you implicitally know you have an IPv4 address, and if you have a sockaddr_in6 then you implicitally know you have an IPv6 address. You have to specify that information to inet_ntop() so it knows how to interpret the data you pass in to it:

struct sockaddr_in sa;
inet_ntop(AF_INET, &(sa.sin_addr), ...);

.

struct sockaddr_in6 sa;
inet_ntop(AF_INET6, &(sa.sin6_addr), ...);

To help you write family-agnostic code, you should be using sockaddr_storage instead of sockaddr_in or sockaddr_in6 directly when possible. sockaddr_storage is large enough in size to hold both sockaddr_in and sockaddr_in6 structs. Since both structs define a family field at the same offset and size, sockaddr_storage can be used with any API that operates on sockaddr* pointers (connect(), accept(), bind(), getsockname(), getpeername(), etc).

However, inet_ntop() does not fall into that category, so you have to pull apart a sockaddr_storage manually when using inet_ntop(), eg:

struct sockaddr_storage sa;

switch (sa.ss_family)
{
case AF_INET:
    inet_ntop(AF_INET, &(((sockaddr_in*)&sa)->sin_addr), ...);
    break;
case AF_INET6:
    inet_ntop(AF_INET6, &(((sockaddr_in6*)&sa)->sin6_addr), ...);
    break;
}