Re: [PATCH] socket: Use may_alias on sockaddr structs (bug 19622)

[Florian Weimer <fweimer@redhat.com>]

* Sam James:

> Sam James <sam@gentoo.org> writes:
>
>> Florian Weimer <fweimer@redhat.com> writes:
>>
>>> This supports common coding paddings.  GCC before version 8
>>> rejects the may_alias attribute on a struct definition if it was
>>> not present in a previous forward declaration, so this attribute
>>> can only be conditionally applied.
>>>
>>> Tested on i686-linux-gnu, x86_64-linux-gnu.  Built with
>>> build-many-glibcs.py.
>>>
>>> Suggested-by: Marek Polacek <polacek@redhat.com>
>>> Suggested-by: Jakub Jelinek <jakub@redhat.com>
>>
>> Reviewed-by: Sam James <sam@gentoo.org>

Thanks.

> Also, on reflection, consider citing the POSIX change I mentioned on
> Bugzilla in the commit message too.
>
> I think it's useful in making clear this isn't (just) a QoI change?
>
> (https://austingroupbugs.net/view.php?id=1641)

I'm not sure we implement this today, particularly this part:

| Similarly, when a pointer to a sockaddr_storage or sockaddr structure
| is converted to a pointer to a protocol-specific address structure,
| the compiler shall treat an access (using this converted pointer) to
| the stored value of any member of the protocol-specific structure as
| permissible.

This seems to suggest that accessing uninitialized data or fields not
present in the original object (after casting to larger struct) has some
defined behavior, without actually assigning any meaning to it.

POSIX could have said that the implementation should behave as if there
is a definition

union
{
  struct sockaddr sa;
  struct sockaddr_in sin;
  struct sockaddr_in6 sin6;
  …
  struct sockaddr_storage ss;
} <implementation-specified>;

in every program.  Then the desired behavior would follow from C's
impossible-to-implement rule about union members and aliasing.

I can perhaps say that it partially addresses Austin Groups issue 1641.

Thanks,
Florian