A NOTE has been added to this issue. ====================================================================== 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: Under Review 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 ====================================================================== Date Submitted: 2023-03-18 07:52 UTC Last Modified: 2023-04-06 15:42 UTC ====================================================================== Summary: sockaddr_storage is not alias safe ======================================================================
---------------------------------------------------------------------- (0006255) eblake (manager) - 2023-04-06 15:42 https://austingroupbugs.net/view.php?id=1641#c6255 ---------------------------------------------------------------------- Interpretation response ------------------------ The standard clearly states that 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 maps onto the sa_family field of the sockaddr structure and when a pointer to a sockaddr_storage structure is cast as a pointer to a protocol-specific address structure, the ss_family field maps onto a field of that structure that is of type sa_family_t and that identifies the protocol’s address family, and conforming implementations must conform to this. Rationale: ------------- In stating these field mapping requirements when a cast operator is applied to the various socket address structures, the standard defines the behavior in circumstances where the behavior is undefined in the ISO C standard. The onus is on implementations to ensure that these mappings are as described in the standard, making use of implementation-specific extensions if necessary, even though this is not stated explicitly. Notes to the Editor (not part of this interpretation): ------------------------------------------------------- On page 386 line 13115 section <sys/socket.h> DESCRIPTION, change: <blockquote>When a pointer to a <b>sockaddr_storage</b> structure is cast as a pointer to a <b>sockaddr</b> structure, the <i>ss_family</i> field of the <b>sockaddr_storage</b> structure shall map onto the <i>sa_family</i> field of the <b>sockaddr</b> structure. When a pointer to a <b>sockaddr_storage</b> structure is cast as a pointer to a protocol-specific address structure, the <i>ss_family</i> field shall map onto a field of that structure that is of type <b>sa_family_t</b> and that identifies the protocol’s address family.</blockquote> to: <blockquote>When a pointer to a <b>sockaddr_storage</b> structure is cast as a pointer to a <b>sockaddr</b> structure, or vice versa, the <i>ss_family</i> field of the <b>sockaddr_storage</b> structure shall map onto the <i>sa_family</i> field of the <b>sockaddr</b> structure. When a pointer to a <b>sockaddr_storage</b> structure is cast as a pointer to a protocol-specific address structure, or vice versa, the <i>ss_family</i> field shall map onto a field of that structure that is of type <b>sa_family_t</b> and that identifies the protocol’s address family. When a pointer to a <b>sockaddr</b> structure is cast as a pointer to a protocol-specific address structure, or vice versa, the <i>sa_family</i> field shall map onto a field of that structure that is of type <b>sa_family_t</b> 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 in accessing the <b>sa_family_t</b> member of these structures when compiling conforming application (xref to XBD section 2.2) source files.</blockquote> On page 390 line 13260 section <sys/socket.h> APPLICATION USAGE, append a sentence: <blockquote>Note that this example only deals with size and alignment; see RATIONALE for additional issues related to these structures.</blockquote> On page 390 line 13291 section <sys/socket.h>, change RATIONALE from "None" to: <blockquote>Note that defining the <b>sockaddr_storage</b> and <b>sockaddr</b> structures using only mechanisms defined in early editions of the ISO C standard may produce aliasing diagnostics when applications use casting between pointers to the various socket address structures. Because of the large body of existing code utilizing sockets in a way that could trigger undefined behavior due to strict aliasing rules, this standard mandates that these structures can alias each other for accessing the <b>sa_family_t</b> member of the structures, so as to preserve well-defined semantics. An implementation's header files may need to use anonymous unions, or even an implementation-specific extension, to comply with the requirements of this standard.</blockquote> 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 2023-03-30 15:22 eblake Tag Attached: issue8 2023-04-03 16:31 eblake Status Resolved => Under Review 2023-04-03 16:31 eblake Resolution Accepted As Marked => Reopened 2023-04-03 16:36 eblake Note Added: 0006249 2023-04-03 22:42 steffen Note Added: 0006253 2023-04-03 22:44 steffen Note Added: 0006254 2023-04-06 15:42 eblake Note Added: 0006255 ======================================================================
