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 <rouca@xxxxxxxxxx> Reported-by: Alejandro Colomar <alx@xxxxxxxxxx> Cc: glibc <libc-alpha@xxxxxxxxxxxxxx> Cc: GCC <gcc@xxxxxxxxxxx> Cc: Eric Blake <eblake@xxxxxxxxxx> Cc: Stefan Puiu <stefan.puiu@xxxxxxxxx> Cc: Igor Sysoev <igor@xxxxxxxxx> Cc: Rich Felker <dalias@xxxxxxxx> Cc: Andrew Clayton <andrew@xxxxxxxxxxxxxxxxxx> Cc: Richard Biener <richard.guenther@xxxxxxxxx> Cc: Zack Weinberg <zack@xxxxxxxxxxxx> Cc: Florian Weimer <fweimer@xxxxxxxxxx> Cc: Joseph Myers <joseph@xxxxxxxxxxxxxxxx> Cc: Jakub Jelinek <jakub@xxxxxxxxxx> Cc: Sam James <sam@xxxxxxxxxx> Signed-off-by: Alejandro Colomar <alx@xxxxxxxxxx> --- 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
