From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5100 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 21:45:39 +0200 Message-ID: References: <20140507031306.GA26963@brightrain.aerifal.cx> <20140507230729.GD26358@brightrain.aerifal.cx> <20140508174138.GJ26358@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 1399578358 16265 80.91.229.3 (8 May 2014 19:45:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 8 May 2014 19:45:58 +0000 (UTC) Cc: musl@lists.openwall.com To: Rich Felker Original-X-From: musl-return-5105-gllmg-musl=m.gmane.org@lists.openwall.com Thu May 08 21:45:53 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 1WiUGO-000365-UR for gllmg-musl@plane.gmane.org; Thu, 08 May 2014 21:45:53 +0200 Original-Received: (qmail 3516 invoked by uid 550); 8 May 2014 19:45:52 -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 3508 invoked from network); 8 May 2014 19:45:51 -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=J6FTnVbCISpzad589jNlN1UfnVUhQEC28FPmu3bVpjQ=; b=V5oPxpCTro2/QdBKRx1loCKp+s5AIeNruFFAumn3CShHg/bcNRUioHiUSRLBOp8fol 7qsGrH/ZwP0ISRT5vg0EXEanMiCYiDJJ70AGexuSrHMeWPY1vU6OZK4x7/JRcZN3KN0/ YJmRiukZfogtOWcaPTo0gp8SeDjxgv581cihKSnqcAf098VBB7+pX2yRzFwBkHB2Uj04 xpXbZ1vgLrU+2OmpTDnkNdVzeBXTMoILpnHuDr2QbUkleJUVR+JP2mMf8d3ykRpyU90O 5GUOKQfxi1BHqLoNdywCwGB6mvrd5p10XkzFZTheoWs1aGK2PVIQTT3EGpRoyA2ZxRi6 4A9g== X-Gm-Message-State: ALoCoQmHNlC4SmBO1vbUIFKKo5vWDmJjgyA5KUCJOJdE87wJgBF3aaC5bQyEA2MXm7CwQY5Ukv64 X-Received: by 10.50.141.232 with SMTP id rr8mr11972410igb.48.1399578339877; Thu, 08 May 2014 12:45:39 -0700 (PDT) In-Reply-To: <20140508174138.GJ26358@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:5100 Archived-At: 2014-05-08 19:41 GMT+02:00 Rich Felker : > On Thu, May 08, 2014 at 06:41:19PM +0200, Pawe=C5=82 Dziepak wrote: >> > 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. > > Indeed. This is not an ABI issue with libc.so, but it's an API > difference that translates into an ABI difference between third-party > translation units if they use max_align_t as you've described. Whether > we care, I'm not sure. At least historically there were other cases > like this in musl where type sizes differed in ways that didn't affect > libc ABI but did affect ABI between third-party programs (jmp_buf > comes to mind) but most if not all of these were changed. > > I'm not strongly opposed to imposing the 8-byte alignment requirement > on malloc (it would be hard to make malloc work on smaller granularity > anyway, and most archs need 8-byte alignment anyway for long long and > for double) but I generally dislike the inconsistency of defining > max_align_t in a semi-absurd way on i386, as well as the issue of > having to use non-portable definitions and/or arch-specific ones. I agree. The question remains, though, whether the consequences of defining max_align_t differently are acceptable. > BTW in your above example, it's not even clear to me if that use of > alignas is valid. It makes no sense for an object to have an alignment > that does not divide its type (imagine if you added [2] to the end of > bar) and in other places (like the contract of aligned_alloc) > alignments that do not divide the size are explicitly illegal. I'd > like to understand this before making a decision. 6.7.5 doesn't mention such requirement. _Alignas, obviously, cannot reduce the alignment requirement and the specified alignment has to has to be either a valid fundamental alignment or valid extended alignment supported by the implementation. Moreover, 6.2.8 requires that valid alignment is a nonnegative integral power of two. As for the additional requirement in contract of aligned_alloc 7.22.3.1 states that the requested alignment has to be valid and divide size of the requested memory block. I don't see how that would disallow using in alignas alignment larger than the size of the object. Pawe=C5=82