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: Pending Final Accepted Text: see https://austingroupbugs.net/view.php?id=1641#c6255 ====================================================================== Date Submitted: 2023-03-18 07:52 UTC Last Modified: 2023-04-06 20:50 UTC ====================================================================== Summary: sockaddr_storage is not alias safe ======================================================================
---------------------------------------------------------------------- (0006258) steffen (reporter) - 2023-04-06 20:50 https://austingroupbugs.net/view.php?id=1641#c6258 ---------------------------------------------------------------------- RFC 2553 defines struct sockaddr_storage { sa_family_t __ss_family; /* address family */ /* Following fields are implementation specific */ char __ss_pad1[_SS_PAD1SIZE]; /* 6 byte pad, this is to make implementation /* specific pad up to alignment field that */ /* follows explicit in the data structure */ int64_t __ss_align; /* field to force desired structure */ /* storage alignment */ char __ss_pad2[_SS_PAD2SIZE]; /* 112 byte pad to achieve desired size, */ /* _SS_MAXSIZE value minus size of ss_family */ /* __ss_pad1, __ss_align fields is 112 */ }; So sockaddr has a 64-bit alignment. This is as good as it gets but for long double and the newish 128-bit integer types (needed to count false political and "economic" decisions i presume; and whatever). Linux uses /* * Desired design of maximum size and alignment (see RFC2553) */ #define _K_SS_MAXSIZE 128 /* Implementation specific max size */ typedef unsigned short __kernel_sa_family_t; /* * The definition uses anonymous union and struct in order to control the * default alignment. */ struct __kernel_sockaddr_storage { union { struct { __kernel_sa_family_t ss_family; /* address family */ /* Following field(s) are implementation specific */ char __data[_K_SS_MAXSIZE - sizeof(unsigned short)]; /* space to achieve desired size, */ /* _SS_MAXSIZE value minus size of ss_family */ }; void *__align; /* implementation specific desired alignment */ }; }; which could end up with 32-bit on 32-bit hosts i am afraid. Looks like a step back compared to RFC 2553 where the 64-bit field emanates all over the place, no? And gives correct alignment but for long double or 128-bit extension no matter what sockaddr actually can be. Why make it more complicated as it is, especially with a POSIX that bases upon ISO C99? Isn't that a bug in Linux instead, as above?? Surely my understanding is from the last century, anyhow. 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 ======================================================================
