From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: [PATCH] add definition of max_align_t to stddef.h
Date: Wed, 7 May 2014 00:29:12 -0400 [thread overview]
Message-ID: <20140507042912.GA27456@brightrain.aerifal.cx> (raw)
In-Reply-To: <5369B32E.9060108@gentoo.org>
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
next prev parent reply other threads:[~2014-05-07 4:29 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-06 10:35 Paweł Dziepak
2014-05-07 3:13 ` Rich Felker
2014-05-07 4:14 ` Luca Barbato
2014-05-07 4:29 ` Rich Felker [this message]
2014-05-07 5:12 ` Luca Barbato
2014-05-07 22:48 ` Rich Felker
2014-05-08 12:07 ` Luca Barbato
2014-05-08 14:25 ` Rich Felker
2014-05-07 9:28 ` Paweł Dziepak
2014-05-07 23:07 ` Rich Felker
2014-05-08 10:57 ` Szabolcs Nagy
2014-05-08 14:11 ` Rich Felker
2014-05-08 16:41 ` Paweł Dziepak
2014-05-08 17:41 ` Rich Felker
2014-05-08 18:45 ` Jens Gustedt
2014-05-08 19:11 ` Paweł Dziepak
2014-05-08 19:22 ` Jens Gustedt
2014-05-08 19:45 ` Paweł Dziepak
2014-05-08 20:02 ` Rich Felker
2014-05-08 20:45 ` Paweł Dziepak
-- strict thread matches above, loose matches on Subject: below --
2014-04-30 20:23 Pawel Dziepak
2014-04-30 21:42 ` Szabolcs Nagy
2014-04-30 22:43 ` Rich Felker
2014-05-04 2:52 ` Paweł Dziepak
2014-05-04 11:42 ` Paweł Dziepak
2014-05-07 5:02 ` Jens Gustedt
2014-05-04 2:36 ` Paweł Dziepak
2014-05-04 5:02 ` Rich Felker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140507042912.GA27456@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).