Date: Wed, 07 May 2014 07:12:39 +0200 From: Luca Barbato <lu_zero@...too.org> To: musl@...ts.openwall.com Subject: Re: [PATCH] add definition of max_align_t to stddef.h 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
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.