From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5067 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] add definition of max_align_t to stddef.h Date: Tue, 6 May 2014 23:13:06 -0400 Message-ID: <20140507031306.GA26963@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1399432408 4727 80.91.229.3 (7 May 2014 03:13:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 7 May 2014 03:13:28 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5073-gllmg-musl=m.gmane.org@lists.openwall.com Wed May 07 05:13:21 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1WhsIL-0000LM-Cw for gllmg-musl@plane.gmane.org; Wed, 07 May 2014 05:13:21 +0200 Original-Received: (qmail 7687 invoked by uid 550); 7 May 2014 03:13:20 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 7679 invoked from network); 7 May 2014 03:13:19 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5067 Archived-At: On Tue, May 06, 2014 at 12:35:55PM +0200, Paweł Dziepak wrote: > >> would be a good thing to mach the definition gcc and clang use, i.e. > >> something like that: > >> > >> union max_align_t { > >> alignas(long long) long long _ll; > >> alignas(long double) long double _ld; > >> }; > > > > This should not give results different from omitting the "alignas". > > The only reason it does give different results is a bug in GCC, so we > > should not be copying this confusing mess that's a no-op for a correct > > compiler. (Applying alignas(T) to type T is always a no-op.) > > I should have checked whether GCC 4.9 has changed before sending that. > As I said earlier, alignof in 4.9 seems to be fixed and on i386 for > fundamental types values <=4 are returned. alignof(max_align_t) > remains 8, though. Then GCC still has a bug. The above definition should give an alignment of 4, not 8. Neither alignas(long long) nor alignas(long double) should impose 8-byte alignment. > However, while 4, undobtedly, is the expected value of > alignof(max_align_t) I don't think that 8 is really wrong (well, from > the C11 point of view). The standard is not very specific about what > max_align_t really should be and if the compiler supports larger > alignment in all contexts there is no reason that alignof(max_align_t) > cannot be larger than alignof() of the type with the strictest > alignment requirements. > Obviously, since max_align_t is the part of ABI it is not like the > implementation can set alignof(max_align_t) to any value or it would > risk compatibility problems with binaries compiled with different > max_align_t. Since both GCC and Clang already define max_align_t so > that its alignment is 8 on i386 I think that Musl should do the same. If we want to achieve an alignment of 8, the above definition is wrong; it will no longer have alignment 8 once the bug is fixed. However I'm not convinced it's the right thing to do. Defining it as 8 is tightening malloc's contract to always return 8-byte-aligned memory (note that it presently returns at least 16-byte alignment anyway, but this is an implementation detail that's not meant to be observable, not part of the interface contract). Rich