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