Hi Eric! On 3/30/23 17:22, Austin Group Bug Tracker via austin-group-l at The Open Group wrote: > > The following issue has been RESOLVED. > ====================================================================== > https://austingroupbugs.net/view.php?id=1641 > ====================================================================== > Reported By: bastien > Assigned To: > ====================================================================== > Project: 1003.1(2016/18)/Issue7+TC2 > Issue ID: 1641 > Category: System Interfaces > Type: Clarification Requested > Severity: Editorial > Priority: normal > Status: Resolved > Name: Bastien Roucaries > Organization: debian > User Reference: > Section: sys/socket.h > Page Number: Application usage > Line Number: sockaddr_storage > Interp Status: --- > Final Accepted Text: see > https://austingroupbugs.net/view.php?id=1641#c6238 > Resolution: Accepted As Marked > Fixed in Version: > ====================================================================== > Date Submitted: 2023-03-18 07:52 UTC > Last Modified: 2023-03-30 15:22 UTC > ====================================================================== > Summary: sockaddr_storage is not alias safe > ====================================================================== > > Issue History > Date Modified Username Field Change > ====================================================================== > 2023-03-18 07:52 bastien New Issue > 2023-03-18 07:52 bastien Name => Bastien Roucaries > 2023-03-18 07:52 bastien Organization => debian > 2023-03-18 07:52 bastien Section => sys/socket.h > 2023-03-18 07:52 bastien Page Number => Application usage > 2023-03-18 07:52 bastien Line Number => sockaddr_storage > 2023-03-18 07:53 bastien Note Added: 0006207 > 2023-03-18 07:53 bastien Issue Monitored: bastien > 2023-03-20 13:20 wlerch Note Added: 0006208 > 2023-03-20 13:38 bastien Note Added: 0006209 > 2023-03-20 23:06 steffen Note Added: 0006211 > 2023-03-21 12:01 hvd Note Added: 0006212 > 2023-03-21 23:09 sam_james Note Added: 0006215 > 2023-03-21 23:33 steffen Note Added: 0006216 > 2023-03-22 09:42 bastien Note Added: 0006217 > 2023-03-22 21:56 steffen Note Added: 0006227 > 2023-03-30 15:20 eblake Note Added: 0006238 > 2023-03-30 15:22 eblake Interp Status => --- > 2023-03-30 15:22 eblake Final Accepted Text => see > https://austingroupbugs.net/view.php?id=1641#c6238 > 2023-03-30 15:22 eblake Status New => Resolved > 2023-03-30 15:22 eblake Resolution Open => Accepted As > Marked Thanks for taking care of this bug! On 3/30/23 17:20, Austin Group Bug Tracker via austin-group-l at The Open Group wrote: > On page 386 line 13115 section <sys/socket.h> DESCRIPTION, change: > > When a pointer to a sockaddr_storage structure is cast as a pointer to a sockaddr structure, the ss_family field of the sockaddr_storage structure shall map onto the sa_family field of the sockaddr structure. When a pointer to a sockaddr_storage structure is cast as a pointer to a protocol-specific address structure, the ss_family field shall map onto a field of that structure that is of type sa_family_t and that identifies the protocol’s address family. > > to: > > When a pointer to a sockaddr_storage structure is cast as a pointer to a sockaddr structure, or vice versa, the ss_family field of the sockaddr_storage structure shall map onto the sa_family field of the sockaddr structure. When a pointer to a sockaddr_storage structure is cast as a pointer to a protocol-specific address structure, or vice versa, the ss_family field shall map onto a field of that structure that is of type sa_family_t and that identifies the protocol’s address family. When a pointer to a sockaddr structure is cast as a pointer to a protocol-specific address structure, or vice versa, the sa_family field shall map onto a field of that structure that is of type sa_family_t and that identifies the protocol’s address family. Additionally, the structures shall be defined in such a way that these casts do not cause the compiler to produce diagnostics about aliasing issues when compiling conforming application (xref to XBD section 2.2) source files. I will add a CAVEATS section in sockaddr(3type) covering this, and will CC you just to check. > > > > On page 390 line 13260 section <sys/socket.h> APPLICATION USAGE, append a sentence: > > Note that this example only deals with size and alignment; see RATIONALE for additional issues related to these structures. > > > > On page 390 line 13291 section <sys/socket.h>, change RATIONALE from "None" to: > > Note that defining the sockaddr_storage and sockaddr structures using only mechanisms defined in editions of the ISO C standard prior to the 2011 edition (C11) may produce aliasing diagnostics when used in C11 and later editions of the ISO C standard. Because of the large body of existing code utilizing sockets in a way that was well-defined in the 1999 edition of the ISO C standard (C99) but could trigger undefined behavior if C11/C17 aliasing detection were enforced, this standard mandates that casts between pointers to the various socket address structures do not produce aliasing diagnostics, so as to preserve well-defined semantics. An implementation's header files may need to use anonymous unions, or even an implementation-specific extension such as a <tt>[[__may_alias__]]</tt> attribute, to comply with the requirements of this standard. I'm not sure how aliasing rules changed from C99 to C11. Wasn't aliasing already in C99 (and also in C89)? I believe this was covered by 6.5.7, which is the same in both C99 and C11. <https://port70.net/~nsz/c/c11/n1570.html#6.5p7> <https://port70.net/~nsz/c/c99/n1256.html#6.5p7> Cheers, Alex -- <http://www.alejandro-colomar.es/> GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
