Hi!I just received a report about struct sockaddr_storage in the man pages. It reminded me of some concern I've always had about it: it doesn't seem to be a usable type.
It has some alignment promises that make it "just work" most of the time, but it's still a UB mine, according to ISO C.
According to strict aliasing rules, if you declare a variable of type 'struct sockaddr_storage', that's what you get, and trying to access it later as some other sockaddr_8 is simply not legal. The compiler may assume those accesses can't happen, and optimize as it pleases.
That means that one needs to declare a union with all possible sockaddr_* types that are of interest, so that access as any of them is later allowed by the compiler (of course, the user still needs to access the correct one, but that's of course).
In that union, one could add a member that is of type sockaddr_storage for getting a more consistent structure size (for example, if some members are conditional on preprocessor stuff), but I don't see much value in that. Especially, given this comment that Igor Sysoev wrote in NGINX Unit's source code:
* struct sockaddr_storage is: * 128 bytes on Linux, FreeBSD, MacOSX, NetBSD; * 256 bytes on Solaris, OpenBSD, and HP-UX; * 1288 bytes on AIX. * * struct sockaddr_storage is too large on some platforms * or less than real maximum struct sockaddr_un length. Which makes it even more useless as a type.Should we warn about uses of this type? Should we recommend against using it in the manual page, since there's no legitimate uses of it?
Cheers, Alex -- <http://www.alejandro-colomar.es/>
OpenPGP_signature
Description: OpenPGP digital signature
