[PATCH 2/3] Document malloc alignment
Paul Eggert
eggert@cs.ucla.edu
Sat Feb 7 08:47:54 GMT 2026
On 2026-02-06 04:18, Wilco Dijkstra wrote:
>> +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.
Makes sense.
> Neither might future versions of GLIBC malloc
The fact that glibc malloc always aligns to 16 or 8, even for smaller
requests, has been documented in the glibc manual for some time. If we
plan to stop guaranteeing this, we should say so in the manual,
something like "Currently malloc always aligns to 16 or 8 but this might
stop being true in the future."
More information about the Libc-alpha
mailing list