[SOLVED] does windows networking code break the strict aliasing rules?

does windows networking code break the strict aliasing rules?

As I was told here: can you typecast an int into 4 chars using structs?, typecasting a struct into another struct pointer is against the "strict aliasing rules". But I think that in C Windows programming, exactly this practice is used.

Here is an example with the 2nd argument of the bind() function:

struct sockaddr_in sockaddrinstance; 
//changed the name a bit for better readability (before: `struct sockaddr_in sockaddr`, after: `struct sockaddr_in sockaddrinstance`)

bind(ListenSocket,  (SOCKADDR*) &sockaddrinstance, sizeof(sockaddr));

Here is the bind() function of the winsock2.h API. I added the documentation you see in the manual page, but shortened it a bit for better readability. You can check the actual resource if you want if you think I misinterpreted something:

bind function:
https://learn.microsoft.com/de-de/windows/win32/api/winsock2/nf-winsock2-bind

int WSAAPI bind(
  [in] SOCKET         s,
  [in] const sockaddr *name,
  [in] int            namelen
);

sockaddr_in struct:
https://learn.microsoft.com/de-de/windows/win32/api/winsock/ns-winsock-sockaddr_in

typedef struct sockaddr_in {
  short          sin_family;
  u_short        sin_port;
  struct in_addr sin_addr;
  char           sin_zero[8];
} SOCKADDR_IN;

sockaddr struct:
https://learn.microsoft.com/de-de/windows/win32/winsock/sockaddr-2

typedef struct sockaddr {
    ushort  sa_family;
    char    sa_data[14];
}SOCKADDR;

Solution

If you have an object of type x and a pointer to that object, then casting the pointer into a pointer to an incompatible type followed by de-referencing is what violates strict aliasing (and possibly alignment etc other forms of undefined behavior too).

The casting in itself is not a strict aliasing violation. It might however in theory be an alignment problem, in case different pointer types don't have the same alignment for the pointed-at type. That's not going to be the case in Windows though. So I don't quite see the problem.

However, the Windows API is known to use all manner of dirty tricks and bad practices (just like POSIX), not necessarily conforming to the ISO C standard (or ISO C++ standard, these days).