[Bug libc/20111] struct sockaddr_storage cannot be aggregate-copied
rguenther at suse dot de
sourceware-bugzilla@sourceware.org
Wed May 18 07:54:00 GMT 2016
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.
More information about the Glibc-bugs
mailing list