On 4/21/23 16:58, Alejandro Colomar wrote: > Hi Eric, > > On 4/14/23 18:08, Zack Weinberg via Libc-alpha wrote: >> On 2023-04-06 3:37 PM, Eric Blake wrote: >>> Since Issue 7 is tied to C99, and Issue 8 will be tied to C17, both of >>> which use the same section number despite being a different edition of >>> the C standard, being that specific may work. Or, we might try >>> something focusing more on wording instead of document location, as >>> in: >>> >>> Additionally, the structures shall be defined in such a way that the >>> compiler treats an access to the stored value of the sa_family_t >>> member of any of these structures, via an lvalue expression whose type >>> involves any other one of these structures, as permissible even if the >>> types involved would not otherwise be deemed compatible with the >>> effective type of the object ultimately being accessed. > > The wording I see in <https://austingroupbugs.net/view.php?id=1641#c6262> > doesn't seem to cover the case of aliasing a sockaddr_storage as a > protocol-specific address for setting other members. > > Aliasing rules don't allow one to declare an object of type > sockaddr_storage and then fill the structure as if it were another > structure, even if alignment and size are correct. We would need > some wording that says something like: > > When a pointer to a sockaddr_storage structure is first aliased as a > pointer to a protocol-specific address structure, the effective type > of the object will be set to the protocol-specific structure. > > This is similar to what happens when malloc(3) is assigned to a > non-character type. That's a big hammer, but it does the job. Maybe > we would need some looser language? I CCd GCC, in case they have > concerns about this wording. > > Cheers, > Alex > >> >> I quite like this way of putting it. It subsumes both what I wrote and >> the related potential headache with deciding whether the sa_family_t >> field is considered an object or just a range of bytes within a larger >> object. >> >> zw >
For the man pages, I've rewritten it to the following: $ git diff diff --git a/man3type/sockaddr.3type b/man3type/sockaddr.3type index 2fdf56c59..e610aa0f5 100644 --- a/man3type/sockaddr.3type +++ b/man3type/sockaddr.3type @@ -117,6 +117,14 @@ .SH HISTORY was invented by POSIX. See also .BR accept (2). +.PP +These structures were invented before modern ISO C strict-aliasing rules. +If aliasing rules are applied strictly, +these structures would be impossible to use +without invoking Undefined Behavior (UB). +POSIX Issue 8 will fix this by requiring that implementations +make sure that these structures +can be safely used as they were designed. .SH NOTES .I socklen_t is also defined in I guess this is simple enough that it should work as documentation. -- <http://www.alejandro-colomar.es/> GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5
OpenPGP_signature
Description: OpenPGP digital signature
