[PATCH 2/3] Document malloc alignment
Wilco Dijkstra
Wilco.Dijkstra@arm.com
Fri Feb 6 12:18:01 GMT 2026
Hi,
> +In @theglibc{}, the block that @code{malloc} gives you is guaranteed
> +to be aligned so that its address is a multiple of
> +@code{alignof (max_align_t)}, so that it can hold object types
> +with any fundamental alignment and without stricter alignment specifiers.
> +On @gnusystems{}, this means the address is a multiple of 16 or of 8,
> +depending on the system.
> +Only rarely is any higher boundary (such as a page
> boundary) necessary; for those cases, use @code{aligned_alloc} or
> @code{posix_memalign} (@pxref{Aligned Memory Blocks}).
> I think this should cross-reference Replacing malloc, and mention that
> malloc replacements sometimes do not follow this rule.
Neither might future versions of GLIBC malloc... We should be careful
about making hard guarantees that we cannot keep indefinitely into the
future. There are small-block allocators that give you 4-byte alignment
for a 4-byte block. There is also a potential optimization to return special
values for malloc (0).
Whether we want to implement this is an orthogonal question - but the
key is that we don't want people to write applications that crash if any
malloc block is not 16-byte aligned - that's just incorrect.
So we should give the alignment guarantee only for blocks larger
than max_align_t.
Cheers,
Wilco
More information about the Libc-alpha
mailing list