[PATCH] malloc: Improve memalign alignment handling

[Paul Eggert]

On 2026-03-02 05:36, Wilco Dijkstra wrote:

> Since it computes a difference in bitwidth using clz, it must do the clz on
> the same type. We could switch to bitwidth for that expression too since
> it then no longer relies on the size of the types. Let me check if it generates
> the same code.

Thanks for explaining. Would make sense to count the bits you need 
directly, rather than subtracting.


And following up on old-time trivia:

>>> Note POSIX requires alignment to be both a power of 2 and a multiple of
>>> sizeof (void *), so it also requires that the pointer size must be a power of 2.
>>
>> But the POSIX wording for posix_memalign doesn't say "and". It says "The
>> value of alignment shall be a power of two multiple of sizeof (void *)".
>> Hence the alignment could be (say) 48 when sizeof (void *) is 6.
> 
> Maybe they changed it recently, but that's impossible to support in general.
> You'd have to set the minimum alignment to least common multiple - if you
> have 16-byte and 6 byte types that would be like 48, and structure layout
> will end up with huge amounts of padding.

Actually it is possible to support, so long as it's POSIX.1-2008 (which 
is where they changed the wording) through POSIX.1-2017. Those POSIX 
versions are based on C99, which does not require alignments to be 
powers of 2, nor does it require support for any nontrivial power-of-two 
alignment.

On the ClearPath mainframe I mentioned, char has alignment 1 and all 
other basic types have alignment 6. So there are no types with 16-byte 
alignment and there is no problem supporting POSIX.1-2017. There would 
be a problem supporting C11 and later (which requires alignments to be a 
power of 2), or supporting POSIX.1-2024 (based on C17), but Unisys 
doesn't support those more-recent standards on this platform.