From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10047 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: sockaddr_storage and GCC 6.1 Date: Tue, 24 May 2016 18:36:02 -0400 Message-ID: <20160524223602.GL21636@brightrain.aerifal.cx> References: <20160524220735.GA19259@wilbur.25thandClement.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="G3juXO9GfR42w+sw" X-Trace: ger.gmane.org 1464129383 8737 80.91.229.3 (24 May 2016 22:36:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 24 May 2016 22:36:23 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-10060-gllmg-musl=m.gmane.org@lists.openwall.com Wed May 25 00:36:18 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1b5Kvx-0007zz-BV for gllmg-musl@m.gmane.org; Wed, 25 May 2016 00:36:17 +0200 Original-Received: (qmail 15793 invoked by uid 550); 24 May 2016 22:36:15 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 15774 invoked from network); 24 May 2016 22:36:14 -0000 Content-Disposition: inline In-Reply-To: <20160524220735.GA19259@wilbur.25thandClement.com> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:10047 Archived-At: --G3juXO9GfR42w+sw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, May 24, 2016 at 03:07:35PM -0700, William Ahern wrote: > GCC 6.1 more aggressively decomposes aggregate assignments into a series of > scalar member assignments. This has uncovered an issue with glibc's layout > of struct sockaddr_storage, which has a padding hole from offsets 2 to 8, > precisely where .sin_port and .sin_addr are in struct sockaddr_in. > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71120 > > musl shares this same issue. Specifically, the __ss_align member with an > 8-byte alignment on LP64 archs. You can track the glibc resolution at > > https://sourceware.org/bugzilla/show_bug.cgi?id=20111 > > Or not track it. Reasonable folks can disagree regarding many aspects of > this issue, but I thought it worthwhile to bring to people's attention. I maintain that it's a bug (violation of effective type rules) for a program to attempt to copy sockaddr types using sockaddr_storage, but this is a nasty application bug to track down (usually silent breakage) that's worth avoiding since it's easy. Does the attached patch work? I don't think we should even consider the sorts of may_alias hacks glibc/gcc folks are discussing, though. There's already a gcc option for compiling broken code like that; it's called -fno-strict-aliasing. Rich --G3juXO9GfR42w+sw Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="sockaddr_storage.diff" diff --git a/include/sys/socket.h b/include/sys/socket.h index 6788375..d2bd5df 100644 --- a/include/sys/socket.h +++ b/include/sys/socket.h @@ -286,7 +286,7 @@ struct sockaddr struct sockaddr_storage { - sa_family_t ss_family; + sa_family_t ss_family, __ss_family_pad; unsigned long __ss_align; char __ss_padding[128-2*sizeof(unsigned long)]; }; --G3juXO9GfR42w+sw--