[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