[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5369C0C7.8070208@gentoo.org>
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.
