[PATCH v2 2/4] Document malloc alignment

[Paul Eggert]

On 2026-02-11 14:27, DJ Delorie wrote:

>> +@item
>> +In implementations other than @theglibc{}, a non-null pointer returned
>> +by @code{malloc (@var{size})} is guaranteed to be aligned only for
>> +fundamentally-aligned objects of size at most @code{max (@var{size}, 1)}.
> 
> Suggest "In some implementations other than..." as they're not all like
> the above.

The idea here is that although some implementations may guarantee more 
than this, all implementations guarantee at least this. I'll change the 
wording to try to make this clearer, and add an example as you suggest.

> Suggest an example, like "For example, malloc(4) might only be aligned
> to a 4-byte boundary, rather than an 8 or 16 byte alignment."
> Substitute appropriate sizeof/alignof if desired.

Thanks, will do.

> Do we want to include advice to programmers here?  Such as "Programmers
> must not assume alignment larger than the allocation size, and should
> use aligned_alloc() et al if needed."

Sure, will do that too.

> 
>> +Any non-null pointer returned by @code{realloc} satisfies the same
>> +alignment restrictions as a similar pointer returned by @code{malloc}
>> +with the same size.
>>   @end deftypefun
> 
> Agreed with Florian, this still needs to note that reallocing an
> aligned_alloc chunk may return a chunk of lesser alignment.

That point is addressed in patch 3 of 4.

>> @@ -980,6 +990,12 @@ is declared in @file{stdlib.h}.
>> +In @theglibc{}, the vector is aligned the same way that @code{malloc}
>> +aligns its returned values.  In other implementations, it is merely
>> +aligned suitably for any array of fundamentally-aligned elements each
>> +with size at most @code{max (@var{size}, 1)}.
>> +
> 
> s/it is/it may be/

Thanks, will do.