On Fri, Jan 20, 2023, at 8:40 AM, Alejandro Colomar wrote: > The historical design of `sockaddr_storage` makes it impossible to use > without breaking strict aliasing rules. Not only this type is unusable, > but even the use of other `sockaddr_*` structures directly (when the > programmer only cares about a single address family) is also incorrect, > since at some point the structure will be accessed as a `sockaddr`, and > that breaks strict aliasing rules too. > > So, the only way for a programmer to not invoke Undefined Behavior is to > declare a union that includes `sockaddr` and any `sockaddr_*` structures > that are of interest, which allows later accessing as either the correct > structure or plain `sockaddr` for the sa_family. ... > struct new_sockaddr_storage nss; > > // ... (initialize oss and nss) > > inet_sockaddr2str(&nss.sa); // correct (and has no casts) I think we need to move slowly here and be _sure_ that any proposed change does in fact reduce the amount of UB. This construct, in particular, might not actually be correct in practice: see https://godbolt.org/z/rn51cracn for a case where, if I'm reading it right, the compiler assumes that a write through a `struct fancy *` cannot alter the values accessible through a `struct simple *` even though both pointers point into the same union. (Test case provided by <https://stackoverflow.com/users/363751/supercat>; I don't know any other identifier for them.) zw
