On Jul 27, 2018, at 9:58 AM, Owen Taylor <otaylor@redhat.com> wrote:

On Fri, Jul 27, 2018 at 9:44 AM, Florian Weimer <fweimer@redhat.com> wrote:
On 07/27/2018 03:33 PM, John Reiser wrote:The key principle is that sizeof(foo) must be the stride of an array of foo,

and the array must guarantee alignment of each element in the array.

Why do you think that?  If some documentation claims this is the case for individual objects, we need to fix it.

struct sizes *do* have this property - they are rounded up so that arrays have the correct alignment.
But that certainly doesn't imply that malloc(7) is allowed to give you unaligned memory.



As an x86 person but only occasionally a standardese person, I find the idea that malloc(8) should return a 16-byte-aligned pointer on x86 to be nuts. I can only think of one non-UB way to notice the difference between an 8-byte and 16-byte aligned result, and that way would be to literally cast to (u)intptr_t and look at the low bits.  This is plausibly relevant to certain VMs and tag bit users, but is totally irrelevant to basically anything else.  And 16-byte alignment for small allocations is a giant waste of memory.

So I think that glibc should change its behavior here to match everyone else, and get the ABI document changed if needed.

Frankly, I find it a bit odd that C stack frames on x86_64 want 16 byte alignment, and it took until gcc 4.8 (IIRC) to get proper support to opt out.