Implement C23 memalignment

Paul Eggert eggert@cs.ucla.edu
Thu Oct 2 18:52:31 GMT 2025


On 2025-10-02 10:15, Zack Weinberg wrote:

> I don't like the "<alternative> suffices on all but theoretical platforms"
> wording at all.  It reminds me of all the passive aggressive language about
> how C89 allows for weird possibilities that Will Not Happen On The GNU
> SystemTM, elsewhere in the manual.

Although that *is* what's going on here, we can drop the wording if it's 
unlikable.

> The performance issues can and should be addressed by making this function
> into a compiler intrinsic.

Although eventually that should happen, the issues are more subtle than 
one might think at first. Possibly memalignment will never be quite as 
efficient, depending on the compiler.

> I suggest this wording instead:

Something like that should be fine, though as Joseph noted the wording 
you used wasn't quite right as it mishandled null and over-aligned 
pointers. Also, there's no need for the "presently", or for the "power 
of two" as all alignments are powers of two. And we can condense the 
discussion about builtins, and while were at it say what the example is 
for and mention portability. Something like this, perhaps:

|On all supported systems,
|when @var{p} is a pointer and @var{a} is an alignment,
|the misaligned-pointer test
|@code{@var{p} != NULL && memalignment (@var{p}) < @var{a}}
|is equivalent to @code{((uintptr_t) @var{p} & (@var{a} - 1)) != 0}.
|The latter expression is likely more efficient,
|and is portable to implementations that lack @code{memalignment}.

The idea is to help people see that memalignment is a bit tricky, and to 
explain what it is equivalent to for a plausible use case. This stuff is 
not obvious, so it's helpful to have some discussion about it in the manual.

I'm also happy with the wording in Joseph's PATCH v2, so please ignore 
the above suggestion if you like.


More information about the Libc-alpha mailing list