[Bug libc/20111] struct sockaddr_storage cannot be aggregate-copied

["rguenther at suse dot de" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=20111

--- Comment #2 from rguenther at suse dot de ---
On Wed, 18 May 2016, fweimer at redhat dot com wrote:

> https://sourceware.org/bugzilla/show_bug.cgi?id=20111
> 
> Florian Weimer <fweimer at redhat dot com> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |fweimer at redhat dot com
> 
> --- Comment #1 from Florian Weimer <fweimer at redhat dot com> ---
> POSIX does not require that objects of type struct sockaddr_storage can be
> copied as aggregates (preserving the contents as a bit-wise copy).
> 
> Without compiler support, I do not see how to fix this in a completely 
> reliable way because the dynamic type of the members will always be 
> wrong (and this will be quite visible to the compiler in many cases, as 
> in the referenced GCC PR). If it's sufficient to stick in additional 
> padding fields, then we can make this change.  But I'm not aware that 
> this is a documented GCC extension.

Yes, even if you add padding fields GCCs TBAA aliasing rules may end up
still breaking things.  But at least you'd have -fno-strict-aliasing
as a workaround ...

> It would be nice to have a GCC attribute to mark struct sockaddr_storage as
> unsafe for aggregate copy, so that GCC can warn about this.

Yeah, I thought of this as well.  Needs to be somewhat carefully designed
and specified how it interacts with composition in general and with
composition in C++ (POD and default copy constructor vs. explicit
copy constructor).

Making the struct incomplete would do the trick and force heap
allocation (or allocation via alloca).  But I guess that would break
too much code out in the wild.

-- 
You are receiving this mail because:
You are on the CC list for the bug.