From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5072 Path: news.gmane.org!not-for-mail From: Luca Barbato Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] add definition of max_align_t to stddef.h Date: Wed, 07 May 2014 07:12:39 +0200 Message-ID: <5369C0C7.8070208@gentoo.org> References: <20140507031306.GA26963@brightrain.aerifal.cx> <5369B32E.9060108@gentoo.org> <20140507042912.GA27456@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1399439583 22525 80.91.229.3 (7 May 2014 05:13:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 7 May 2014 05:13:03 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5078-gllmg-musl=m.gmane.org@lists.openwall.com Wed May 07 07:12:56 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 1WhuA4-000207-A2 for gllmg-musl@plane.gmane.org; Wed, 07 May 2014 07:12:56 +0200 Original-Received: (qmail 1578 invoked by uid 550); 7 May 2014 05:12:55 -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 1567 invoked from network); 7 May 2014 05:12:55 -0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Thunderbird/29.0 In-Reply-To: <20140507042912.GA27456@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:5072 Archived-At: On 07/05/14 06:29, Rich Felker wrote: > On Wed, May 07, 2014 at 06:14:38AM +0200, Luca Barbato wrote: >> On 07/05/14 05:13, Rich Felker wrote: >>> 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). >> >> The current natural alignment shouldn't be 32 for AVX and 16 for SSE ? >> >> Not sure how wasteful would be but it would be surely a boon for the >> applications I'm mostly involved. > > If you're working with data that needs additional alignment, you have That's the part that is annoying, the larger register is 32byte in those platforms. > to use aligned_alloc (C11), posix_memalign (POSIX), or memalign > (legacy). Just assuming the result of malloc will be aligned beyond > the alignment requirements of any standard type is unsafe. That we do already obviously, with the additional fun of not having a realloc matching the mentioned functions in most platforms. Having the memory functions 32-byte aligned and a mean to probe for it would simplify a lot of code. lu