[PATCH] sockaddr.3type: Document that sockaddr_storage is the API to be used

[Zack Weinberg]

On Thu, Apr 6, 2023, at 12:31 PM, Alejandro Colomar via Libc-alpha wrote:
> On 4/6/23 18:24, Eric Blake wrote:
>> 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.

If I could suggest an additional change, the focus on aliasing
_diagnostics_ rather misses the point IMHO.  We don't just want the
compiler to _not complain_ about accesses to sa_family_t, we want it to
treat the accesses as _legitimate_.  So, instead of

# Additionally, the structures shall be defined in such a way that
# these casts do not cause the compiler to produce diagnostics about
# aliasing issues in accessing the sa_family_t member of these
# structures when compiling conforming application (xref to XBD section
# 2.2) source files.

may I suggest wording along the lines of

# 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, despite the
# more restrictive rules listed in ISO C section 6.5p7.

zw