POSIX.1 Issue 8 will fix the long-standing issue with sockaddr APIs, which inevitably caused UB either on user code, libc, or more likely, both. sockaddr_storage has been clarified to be implemented in a manner that aliasing it is safe (suggesting a unnamed union, or other compiler magic).
Link: <https://www.austingroupbugs.net/view.php?id=1641> Reported-by: Bastien Roucariès <ro...@debian.org> Reported-by: Alejandro Colomar <a...@kernel.org> Cc: glibc <libc-al...@sourceware.org> Cc: GCC <gcc@gcc.gnu.org> Cc: Eric Blake <ebl...@redhat.com> Cc: Stefan Puiu <stefan.p...@gmail.com> Cc: Igor Sysoev <i...@sysoev.ru> Cc: Rich Felker <dal...@libc.org> Cc: Andrew Clayton <and...@digital-domain.net> Cc: Richard Biener <richard.guent...@gmail.com> Cc: Zack Weinberg <z...@owlfolio.org> Cc: Florian Weimer <fwei...@redhat.com> Cc: Joseph Myers <jos...@codesourcery.com> Cc: Jakub Jelinek <ja...@redhat.com> Cc: Sam James <s...@gentoo.org> Signed-off-by: Alejandro Colomar <a...@kernel.org> --- Hi all, This is my proposal for documenting the POSIX decission of fixing the definition of sockaddr_storage. Bastien, I believe you had something similar in mind; please review. Eric, thanks again for the fix! Could you please also have a look at this? Cheers, Alex man3type/sockaddr.3type | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/man3type/sockaddr.3type b/man3type/sockaddr.3type index 32c3c5bd0..d1db87d5d 100644 --- a/man3type/sockaddr.3type +++ b/man3type/sockaddr.3type @@ -23,6 +23,14 @@ .SH SYNOPSIS .PP .B struct sockaddr_storage { .BR " sa_family_t ss_family;" " /* Address family */" +.PP +.RS 4 +/* This structure is not really implemented this way. It may be +\& implemented with an unnamed union or some compiler magic to +\& avoid breaking aliasing rules when accessed as any other of the +\& sockaddr_* structures documented in this page. See CAVEATS. +\& */ +.RE .B }; .PP .BR typedef " /* ... */ " socklen_t; @@ -122,6 +130,20 @@ .SH NOTES .I <netinet/in.h> and .IR <sys/un.h> . +.SH CAVEATS +To avoid breaking aliasing rules, +programs that use functions that receive pointers to +.I sockaddr +structures should declare objects of type +.IR sockaddr_storage , +which is defined in a way that it +can be accessed as any of the different structures defined in this page. +Failure to do so may result in Undefined Behavior. +.PP +New functions should be written to accept pointers to +.I sockaddr_storage +instead of the traditional +.IR sockaddr . .SH SEE ALSO .BR accept (2), .BR bind (2), -- 2.39.2
