[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140507042912.GA27456@brightrain.aerifal.cx>
Date: Wed, 7 May 2014 00:29:12 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] add definition of max_align_t to stddef.h
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
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.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
