I came across a socket programming tutorial in which it is quoted
\"a pointer to a struct sockaddr_in can be cast to a pointer to a struct sockad
They are of equal size, so no, you don't get any UB!
Proof:
#include <stdio.h>
struct sockaddr {
unsigned short sa_family; // address family, AF_xxx
char sa_data[14]; // 14 bytes of protocol address
};
// src: http://www.gta.ufrj.br/ensino/eel878/sockets/sockaddr_inman.html
struct in_addr {
unsigned long s_addr; // load with inet_aton()
};
struct sockaddr_in {
short int sin_family; // Address family, AF_INET
unsigned short int sin_port; // Port number
struct in_addr sin_addr; // Internet address
unsigned char sin_zero[8]; // Same size as struct sockaddr
};
int main (void) {
printf("%zu\n", sizeof(unsigned short) + sizeof(char) * 14);
printf("%zu\n", sizeof(short int) + sizeof(unsigned short int) + sizeof(struct in_addr) + sizeof(unsigned char) * 8);
return 0;
}
Output:
16
16
A good comment: sockaddr: 2+14=16, sockaddr_in:2+2+4+8=16 – Amer Agovic
You may also want to take a look at this question: Why isn't sizeof for a struct equal to the sum of sizeof of each member?
Please, check this question: Is it possible to cast struct to another?
I am copying the answer of Benoit here too:
This is refered as Type Punning. Here, both structures have the same size, so there is no question of struct size. Although you can cast almost anything to anything, doing it with structures is error-prone.
and this one by Richard J. Ross III too:
This is C's form of "inheritance" (notice the quotes). This works because C does not care about the underlying data in an address, just what you represent it as.
The function determines what structure it actually is by using the sa_family field, and casting it into the proper sockaddr_in inside the function.
The different sizes don't matter. Just like you can pass strings of different lengths to the various string-handling functions, you can pass struct sockaddr
of different lengths to the various socket-handling functions.
The size of the struct sockaddr
is interpreted by the called function per the contents of the sa_family
member of the structure. Note also that all functions that take a struct sockaddr *
address also take a socklen_t
argument that holds the size of the structure being passed.
For example, the struct sockaddr_un structure is 110 bytes:
struct sockaddr_un {
sa_family_t sun_family; /* AF_UNIX */
char sun_path[108]; /* pathname */
};
The called function such as bind() or getpeername() have declarations similar to
int getpeerame(int sockfd, struct sockaddr *addr, socklen_t *addrlen);
for the very reason that the size(s) of various socket structures vary.
Note that the first member of every struct sockaddr_???
is the sa_family
. Thus it's always in the same place.
I'll add to @gsamaras answer by saying that Undefined Behaviour doesn't always means that bad things are about to happen. Undefined Behaviour actually says "we* don't provide any specifications on what should happen next if XYZ occurs".
(*the C++ standard).
this is the place where the OS takes place and say "it is defined by us".
although casting unrelated structs (sockaddr_in
,sockaddr
) may be undefined behaviour by the standard, the OS API specify that it is valid with their API.