[PATCH v2 4/4] malloc: alignment might change in future versions

Paul Eggert eggert@cs.ucla.edu
Wed Feb 11 20:17:37 GMT 2026


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(-)

diff --git a/NEWS b/NEWS
index c63d9d6470..46590a996c 100644
--- a/NEWS
+++ b/NEWS
@@ -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:
 
diff --git a/manual/lang.texi b/manual/lang.texi
index bffe1390e4..a48dc30cff 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.
 
 @strong{Compatibility Note:} The C11 standard introduced @code{max_align_t};
 older compilers may lack the type.
diff --git a/manual/memory.texi b/manual/memory.texi
index 55cb92a0bd..a32aec382c 100644
--- a/manual/memory.texi
+++ b/manual/memory.texi
@@ -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
-- 
2.51.0



More information about the Libc-alpha mailing list