Hi Eric, On 4/6/23 18:24, Eric Blake wrote: > 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 Thanks! That wording (both paragraphs) LGTM. Cheers, Alex -- <http://www.alejandro-colomar.es/> GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
