From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5093 Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Pawe=C5=82_Dziepak?= Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] add definition of max_align_t to stddef.h Date: Thu, 8 May 2014 18:41:19 +0200 Message-ID: References: <20140507031306.GA26963@brightrain.aerifal.cx> <20140507230729.GD26358@brightrain.aerifal.cx> 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: quoted-printable X-Trace: ger.gmane.org 1399567298 30148 80.91.229.3 (8 May 2014 16:41:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 8 May 2014 16:41:38 +0000 (UTC) Cc: musl@lists.openwall.com To: Rich Felker Original-X-From: musl-return-5099-gllmg-musl=m.gmane.org@lists.openwall.com Thu May 08 18:41:33 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 1WiRO0-00053E-GZ for gllmg-musl@plane.gmane.org; Thu, 08 May 2014 18:41:32 +0200 Original-Received: (qmail 3263 invoked by uid 550); 8 May 2014 16:41:31 -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 3255 invoked from network); 8 May 2014 16:41:31 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=WLHHJxkfguK2I/zPFQZnv4rUvjDJIj/22abQCzFEc48=; b=OliVgC0mM7OetG73Bm+c23uwpyrBzrdjos//Do0xPt6XszV0QgqlcQDSz1YDqd73Hc wqW8rkwqHuhtPmd/iErN+0KAwBO2j6SXFFPHujUzv1X5ek4EzXM8moLCdH+zv9FA50lw uSc6spKxOBK+cOzxVtZBAkwd+NAdis+s9zSk64T/dWZqIUVkTsbTYWiiUAYTWg7No2bh SB5H1ekiYtfofFKCyMJss6zgNx5DvnvnJHDMNNfI+E3KNr+XPIediLnHuIvo9xOTTRus ynOhyS+B4TdOltpBFvkbQXeYX9AA4YtqpJyRMmhf1ktOPJIEVoz+KD8CWioeFlQMnB0H qn9Q== X-Gm-Message-State: ALoCoQl2g6Iw8/poWfxONMGY/BAvJ99JJCzP5R7oxb2hZVQIsc+s1Aeg4mzpfxEHAxmbSMnOEJCh X-Received: by 10.50.143.34 with SMTP id sb2mr57299484igb.48.1399567279116; Thu, 08 May 2014 09:41:19 -0700 (PDT) In-Reply-To: <20140507230729.GD26358@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:5093 Archived-At: 2014-05-08 1:07 GMT+02:00 Rich Felker : > On Wed, May 07, 2014 at 11:28:58AM +0200, Pawe=C5=82 Dziepak wrote: >> 2014-05-07 5:13 GMT+02:00 Rich Felker : >> > On Tue, May 06, 2014 at 12:35:55PM +0200, Pawe=C5=82 Dziepak wrote: >> >> 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). >> >> I've mentioned earlier that it seems that the only option is to use >> GCC extensions (i.e. __alignof__) to match their definition of >> max_align_t, just like it is done in this patch: >> http://www.openwall.com/lists/musl/2014/04/28/3 >> It is not nice that GCC forces malloc to support "extended" alignment >> but I don't think there is much that can be done about it. > > I don't see how GCC "forces" this. The definition of max_align_t from > glibc's stddef.h, which we do not use, is what forces it. It is GCC that provides stddef.h, not glibc. > As I see it, we have a choice whether to use the "8" definition on > i386 or use the natural definition, which would yield "4" on i386. > This is not an ABI issue (it does not affect the ability to use > glibc-built object files/binaries/shared libraries with musl, nor the > C++ name mangling ABI) but an API issue. What about something like this? struct foobar { char foo; alignas(max_align_t) char bar; }; The binary representation of this structure depends on the definition of max_align_t and binaries compiled with different alignof(max_align_t) won't be compatible. Pawe=C5=82