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: Interpretation Required Name: Bastien Roucaries Organization: debian User Reference: Section: sys/socket.h Page Number: Application usage Line Number: sockaddr_storage Interp Status: Proposed Final Accepted Text: see https://austingroupbugs.net/view.php?id=1641#c6262 ====================================================================== Date Submitted: 2023-03-18 07:52 UTC Last Modified: 2023-05-25 16:23 UTC ====================================================================== Summary: sockaddr_storage is not alias safe ======================================================================
---------------------------------------------------------------------- (0006290) eblake (manager) - 2023-05-25 16:23 https://austingroupbugs.net/view.php?id=1641#c6290 ---------------------------------------------------------------------- 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 converted to a pointer to a <b>sockaddr</b> structure, or vice versa, the <i>ss_family</i> member of the <b>sockaddr_storage</b> structure shall map onto the <i>sa_family</i> member of the <b>sockaddr</b> structure. When a pointer to a <b>sockaddr_storage</b> structure is converted to a pointer to a protocol-specific address structure, or vice versa, the <i>ss_family</i> member shall map onto a member of that structure that is of type <b>sa_family_t</b> that identifies the protocol’s address family. When a pointer to a <b>sockaddr</b> structure is converted to a pointer to a protocol-specific address structure, or vice versa, the <i>sa_family</i> member shall map onto a member of that structure that is of type <b>sa_family_t</b> that identifies the protocol’s address family. Additionally, the structures shall be defined in such a way that the compiler treats an access to the stored value of the <b>sa_family_t</b> member of any of these structures, via an lvalue expression whose type involves any other one of these structures, as permissible, despite the more restrictive expression rules on stored value access as stated in the ISO C standard. Similarly, when a pointer to a <b>sockaddr_storage</b> or <b>sockaddr</b> structure is converted to a pointer to a protocol-specific address structure, the compiler shall treat an access (using this converted pointer) to the stored value of any member of the protocol-specific structure as permissible. The application shall ensure that the protocol-specific address structure corresponds to the family indicated by the member with type <b>sa_family_t</b> of that structure and the pointed-to object has sufficient memory for addressing all members of the protocol-specific structure.</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 (or other members for protocol-specific structure references), 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 2023-04-06 15:43 eblake Interp Status --- => Pending 2023-04-06 15:43 eblake Final Accepted Text see https://austingroupbugs.net/view.php?id=1641#c6238 => see https://austingroupbugs.net/view.php?id=1641#c6255 2023-04-06 15:43 eblake Status Under Review => Interpretation Required 2023-04-06 15:43 eblake Resolution Reopened => Accepted As Marked 2023-04-06 15:44 eblake Tag Attached: tc3-2008 2023-04-06 15:44 eblake Tag Detached: issue8 2023-04-06 19:24 eblake Note Added: 0006257 2023-04-06 20:50 steffen Note Added: 0006258 2023-04-06 20:55 steffen Note Added: 0006259 2023-04-06 21:08 steffen Note Added: 0006260 2023-04-07 04:53 ajosey Interp Status Pending => Proposed 2023-04-07 04:53 ajosey Note Added: 0006261 2023-04-13 15:45 eblake Note Added: 0006262 2023-04-13 15:46 eblake Final Accepted Text see https://austingroupbugs.net/view.php?id=1641#c6255 => see https://austingroupbugs.net/view.php?id=1641#c6262 2023-04-13 15:48 eblake Note Edited: 0006255 2023-04-13 15:50 eblake Note Edited: 0006255 2023-04-14 15:20 agadmin Note Added: 0006263 2023-04-21 15:24 eblake Note Added: 0006268 2023-05-25 16:23 geoffclare Note Added: 0006289 2023-05-25 16:23 eblake Note Added: 0006290 ======================================================================
