On Fri, Apr 21, 2023 at 05:00:14PM +0200, Alejandro Colomar wrote: > > > > 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.
I'll add that as a comment to the Austin Group page; it seems like a reasonable statement of intent (POSIX already says that struct sockaddr_storage is sufficiently sized and aligned; all that remains is for the compiler to be aware that we intend to use a more-appropriate effective type once we have the storage allocated). > > > > 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 Maybe "extremely difficult" instead of "impossible" to use (if I understand this thread correctly, it is possible to memcpy() from one struct into different storage of a different effective type where the memcpy()'s intermediate aliasing through char* avoids the UB). > +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. It seems fine from my perspective. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
