From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5045 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: Sun, 4 May 2014 01:02:13 -0400 Message-ID: <20140504050213.GA20625@brightrain.aerifal.cx> References: <1398889381-22981-1-git-send-email-pdziepak@quarnos.org> <20140430214250.GI12324@port70.net> 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 1399179754 30292 80.91.229.3 (4 May 2014 05:02:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 4 May 2014 05:02:34 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5049-gllmg-musl=m.gmane.org@lists.openwall.com Sun May 04 07:02:29 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 1WgoZH-0000up-Bs for gllmg-musl@plane.gmane.org; Sun, 04 May 2014 07:02:27 +0200 Original-Received: (qmail 9260 invoked by uid 550); 4 May 2014 05:02:26 -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 9251 invoked from network); 4 May 2014 05:02:25 -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:5045 Archived-At: On Sun, May 04, 2014 at 04:36:03AM +0200, Paweł Dziepak wrote: > 2014-04-30 23:42 GMT+02:00 Szabolcs Nagy : > > * Pawel Dziepak [2014-04-30 22:23:01 +0200]: > >> > >> +TYPEDEF union { long double ld; long long ll; } max_align_t; > > > > this is wrong > > > > - ld and ll identifiers are not reserved for the implementation > > (you could name them _ld, _ll or __ld, __ll etc) > > I will fix that. However, I must admit I don't see why members of the > union (or struct) have to use identifiers reserved for the > implementation. It's not like they can conflict with anything, isn't > it? #define ll 0 #include > > and see previous max_align_t discussion > > http://www.openwall.com/lists/musl/2014/04/28/8 > > > > - compiler implementations are non-conforming on some platforms > > (_Alignof returns inconsistent results for the same object type so > > reasoning about alignments is problematic, there are exceptions > > where this is allowed in c++11 but not in c11) > > > > - max_align_t is part of the abi and your solution is incompatible > > with gcc and clang (your definition gives 4 byte _Alignof(max_align_t) > > on i386 instead of 8) > > The behavior of _Alignof on x86 is indeed quite surprising. I actually It's also wrong. The correct alignment for max_align_t on i386 is 4, not 8. It's a bug that GCC ever returns 8 for alignof on i386. We really need to file a bug against GCC and explain this clearly, because I have a feeling they're going to be opposed to fixing it... > don't see why 8 is the right value and 4 isn't - System V ABI for x86 > doesn't mention any type with alignment 8. Anyway, I agree that it You're completely right; GCC is wrong. > 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.) Rich