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-03 16:36 UTC ====================================================================== Summary: sockaddr_storage is not alias safe ======================================================================
---------------------------------------------------------------------- (0006249) eblake (manager) - 2023-04-03 16:36 https://austingroupbugs.net/view.php?id=1641#c6249 ---------------------------------------------------------------------- Reopened during the 2023-04-03 meeting; https://austingroupbugs.net/view.php?id=1641#c6238 may not be sufficiently precise in its wording (both C99 and C11 section 6.5 paragraph 7 have similar wording on undefined behavior when dereferencing an lvalue of a type not compatible with the effective type of the underlying storage, so claiming that aliasing warnings were only introduced in C11 is wrong). The Austin Group is still working on alternative wording ideas, but consensus from today is that an interpretation request will be needed, along the lines of: 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. 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 ======================================================================
