[v3,4/4] malloc: alignment might change in future versions
Checks
| Context |
Check |
Description |
| redhat-pt-bot/TryBot-apply_patch |
success
|
Patch applied to master at the time it was sent
|
| redhat-pt-bot/TryBot-32bit |
success
|
Build for i686
|
| linaro-tcwg-bot/tcwg_glibc_build--master-aarch64 |
success
|
Build passed
|
| linaro-tcwg-bot/tcwg_glibc_check--master-aarch64 |
success
|
Test passed
|
| linaro-tcwg-bot/tcwg_glibc_build--master-arm |
success
|
Build passed
|
| linaro-tcwg-bot/tcwg_glibc_check--master-arm |
success
|
Test passed
|
Commit Message
This follows up on a comment by Wilco Dijkstra; see:
https://sourceware.org/pipermail/libc-alpha/2026-February/174934.html
* NEWS: Mention this.
* manual/lang.texi (Important Data Types):
Say that alignof (max_align_t) might change.
* manual/memory.texi (Malloc Examples):
Say that alignment guarantee might change for small allocations.
---
NEWS | 7 ++++++-
manual/lang.texi | 2 +-
manual/memory.texi | 8 ++++++--
3 files changed, 13 insertions(+), 4 deletions(-)
Comments
* Paul Eggert:
> diff --git a/manual/lang.texi b/manual/lang.texi
> index 28e7de2b2c..925cdacc1f 100644
> --- a/manual/lang.texi
> +++ b/manual/lang.texi
> @@ -597,7 +597,7 @@ types have a fundamental alignment and lack stricter alignment specifiers.
> In @theglibc{}, the value of @code{alignof (max_align_t)} is 16 on
> most architectures. However, it is 8 on 32-bit architectures that do
> not require 16-byte alignment from @code{malloc} to support predefined
> -types.
> +types. The value may change in future releases.
Can we really change the definition of the type, though? That's close
to an ABI event.
Rest looks okay to me.
Thanks,
Florian
On 2026-02-26 04:47, Florian Weimer wrote:
>> --- a/manual/lang.texi
>> +++ b/manual/lang.texi
>> @@ -597,7 +597,7 @@ types have a fundamental alignment and lack stricter alignment specifiers.
>> In @theglibc{}, the value of @code{alignof (max_align_t)} is 16 on
>> most architectures. However, it is 8 on 32-bit architectures that do
>> not require 16-byte alignment from @code{malloc} to support predefined
>> -types.
>> +types. The value may change in future releases.
> Can we really change the definition of the type, though? That's close
> to an ABI event.
>
> Rest looks okay to me.
Thanks, I installed the patches without that sentence.
However, the manual should discuss the ABI effect of any possible
differences in max_align_t, or in intmax_t/uintmax_t for that matter.
This is relevant partly because C23 (unlike earlier C standards) allows
intmax_t to be narrower than int128_t (assuming the latter type exists,
which it really should with GCC).
I'll propose further patches along those lines.
@@ -13,7 +13,12 @@ Major new features:
Deprecated and removed features, and other changes affecting compatibility:
- [Add deprecations, removals and changes affecting compatibility here]
+* Although malloc and related functions currently return pointers
+ aligned to alignof (max_align_t), the documentation now says future
+ versions of glibc may relax alignment requirements for small allocations.
+ For example, a future malloc (1) might return a pointer with odd
+ alignment, because no object of size 1 can have a fundamental
+ alignment greater than 1.
Changes to build and runtime requirements:
@@ -597,7 +597,7 @@ types have a fundamental alignment and lack stricter alignment specifiers.
In @theglibc{}, the value of @code{alignof (max_align_t)} is 16 on
most architectures. However, it is 8 on 32-bit architectures that do
not require 16-byte alignment from @code{malloc} to support predefined
-types.
+types. The value may change in future releases.
@strong{Compatibility Note:} The C11 standard introduced @code{max_align_t};
older compilers may lack the type.
@@ -653,13 +653,17 @@ savestring (const char *ptr, size_t len)
@end group
@end smallexample
-In @theglibc{}, the block that @code{malloc} gives you is guaranteed
-to be aligned so that its address is a multiple of
+In the current release of @theglibc{}, the block that @code{malloc} gives you is
+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.
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}).
+Future releases of @theglibc{} may relax alignment for small allocations,
+so long as any object with fundamental alignment that fits in the small
+allocation will be properly aligned. For example, a future @code{malloc (1)}
+might return a pointer with odd alignment.
Note that the memory located after the end of the block is likely to be
in use for something else; perhaps a block already allocated by another