On Wed, Apr 05, 2023 at 02:42:04AM +0200, Alejandro Colomar wrote: > Hi Eric, > > I'm going to reply both your emails here so that GCC is CCed, and they can > suggest better stuff. I'm worried about sending something to POSIX without > enough eyes checking it. So this will be a long email. Because your mail landed in a publicly archived mailing list, the POSIX folks saw it anyways ;) ... > > > > Whether gcc already has all the attributes you need is not my area of > > expertise. In my skim of the glibc list conversation, I saw mention > > of attribute [[gnu:transparent_union]] rather than [[__may_alias__]] - > > if that's a better implementation-defined extension that does what we > > need, then use it. The standard developers were a bit uncomfortable > > directly putting [[gnu:transparent_union]] in the standard, but > > [[__may_alias__]] was noncontroversial (it's in the namespace reserved > > for the implementation) > > Not really; implementation-defined attributes are required to use an > implementation-defined prefix like 'gnu::'. So [[__may_alias__]] is > reserved by ISO C, AFAIR. Maybe it would be better to just mention > attributes without any specific attribute name; being fuzzy about it > would help avoid making promises that we can't hold. On this point, the group agreed, and we intentionally loosened to wording to just mention an implementation-defined extension, rather than giving any specific attribute name. ... > > I would just make it more fuzzy about which standard version did what. > How about this?: > > [[ > Note that defining the sockaddr_storage and sockaddr structures using > only mechanisms defined in editions of the ISO C standard may produce > aliasing diagnostics. 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 the various socket > address structures can alias each other for accessing their first member, The sa_family_t member is not necessarily the first member on all platforms (it happens to be first in Linux, but as a counter-example, https://man.freebsd.org/cgi/man.cgi?query=unix&sektion=4 shows sun_family as the second one-byte field in struct sockaddr_un). The emphasis is on derefencing the family member (whatever offset it is at) to learn what cast to use to then safely access the rest of the storage. As such, here's the updated wording that the Austin Group tried today (and we plan on starting a 30-day interpretation feedback window if there are still adjustments to be made to the POSIX wording): https://austingroupbugs.net/view.php?id=1641#c6255 -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
