From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10049 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 19:21:29 -0400 Message-ID: <20160524232129.GN21636@brightrain.aerifal.cx> References: <20160524220735.GA19259@wilbur.25thandClement.com> <20160524223602.GL21636@brightrain.aerifal.cx> <20160524225548.GM21636@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Qo8f1a4rgWw9S/zY" X-Trace: ger.gmane.org 1464132113 17164 80.91.229.3 (24 May 2016 23:21:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 24 May 2016 23:21:53 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-10062-gllmg-musl=m.gmane.org@lists.openwall.com Wed May 25 01:21:47 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 1b5Ldx-0004se-SD for gllmg-musl@m.gmane.org; Wed, 25 May 2016 01:21:45 +0200 Original-Received: (qmail 11854 invoked by uid 550); 24 May 2016 23:21:43 -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 11830 invoked from network); 24 May 2016 23:21:42 -0000 Content-Disposition: inline In-Reply-To: <20160524225548.GM21636@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:10049 Archived-At: --Qo8f1a4rgWw9S/zY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, May 24, 2016 at 06:55:48PM -0400, Rich Felker wrote: > On Tue, May 24, 2016 at 06:36:02PM -0400, Rich Felker wrote: > > 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 > > > 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)]; > > }; > > This is wrong for 64-bit archs; new version attached. > > Rich > diff --git a/include/sys/socket.h b/include/sys/socket.h > index 6788375..c7f244a 100644 > --- a/include/sys/socket.h > +++ b/include/sys/socket.h > @@ -287,6 +287,7 @@ struct sockaddr > struct sockaddr_storage > { > sa_family_t ss_family; > + char __ss_family_pad[sizeof(long)-sizeof(sa_family_t)]; > unsigned long __ss_align; > char __ss_padding[128-2*sizeof(unsigned long)]; > }; And here's a potentially simpler version. Rich --Qo8f1a4rgWw9S/zY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="sockaddr_storage_v3.diff" diff --git a/include/sys/socket.h b/include/sys/socket.h index 6788375..4247915 100644 --- a/include/sys/socket.h +++ b/include/sys/socket.h @@ -287,8 +287,8 @@ struct sockaddr struct sockaddr_storage { sa_family_t ss_family; + char __ss_padding[128-sizeof(long)-sizeof(sa_family_t)]; unsigned long __ss_align; - char __ss_padding[128-2*sizeof(unsigned long)]; }; int socket (int, int, int); --Qo8f1a4rgWw9S/zY--