Re: struct sockaddr_storage

["Zack Weinberg" <zack@owlfolio.org>]

On Thu, Jan 19, 2023, at 9:11 AM, Alejandro Colomar via Libc-alpha wrote:
> 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.

Yeah, struct sockaddr_storage has only one genuine use case in my experience: to
know how big to make the buffer for a call to `getpeername` (or, equivalently,
`accept` with non-null second argument) *when you know that the only address
families you care about are IPv4 and IPv6*. And you can do that just as well with

union {
  struct sockaddr sa;
  struct sockaddr_in sa_in;
  struct sockaddr_in6 sa_in6;
} addrbuf;

which also means fewer aliasing issues.

I'd suggest that the manpages should say:

0. It is almost never the Right Thing to declare a variable of type `struct sockaddr` or `struct sockaddr_storage`.
1. To the maximum extent possible, rely on `getaddrinfo` and `getnameinfo` to deal with socket addresses for you.  Treat them as opaque.
2. When you need to work with a specific socket address type that `getaddrinfo` and `getnameinfo` don't handle, declare a variable of that specific `struct sockaddr_XX` type, and cast its address to `struct sockaddr *` _only_ at the point of call to a function that requires an argument of that type.  For example, AF_LOCAL / struct sockaddr_un usually has to be handled this way.
3. To call `getpeername`, or `accept` with non-null second argument, use a union containing each of the concrete socket address structs for the address families you care about (normally at least _in and _in6).  Also include `struct sockaddr` so you can write `&addrbuf.sa` instead of `(struct sockaddr *)&addrbuf`.

However, like with the string functions, I would not use the word "deprecated".

zw

p.s. see https://stackoverflow.com/a/42190913 for my thoughts on the socket address API in way more detail; feel free to crib from there for the manpages