Isn't struct sockadr_in supposed to work for both IPv4 and IPv6?
c, linux, sockets
Solution
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;
}
Problem
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 ?