From: Paul Eggert <eggert@cs.ucla.edu>
To: libc-alpha@sourceware.org
Cc: Paul Eggert <eggert@cs.ucla.edu>
Subject: [PATCH v3 2/4] Document malloc alignment
Date: Thu, 12 Feb 2026 10:18:12 -0800 [thread overview]
Message-ID: <20260212182031.107003-3-eggert@cs.ucla.edu> (raw)
In-Reply-To: <20260212182031.107003-1-eggert@cs.ucla.edu>
* manual/memory.texi (Malloc Examples, Changing Block Size)
(Allocating Cleared Space):
Document the alignment of the returned value.
---
manual/memory.texi | 31 +++++++++++++++++++++++++++----
1 file changed, 27 insertions(+), 4 deletions(-)
diff --git a/manual/memory.texi b/manual/memory.texi
index f85e8ef26d..614cdc4e46 100644
--- a/manual/memory.texi
+++ b/manual/memory.texi
@@ -652,10 +652,11 @@ savestring (const char *ptr, size_t len)
@end group
@end smallexample
-The block that @code{malloc} gives you is guaranteed to be aligned so
-that it can hold any type of data. On @gnusystems{}, the address is
-always a multiple of eight on 32-bit systems, and a multiple of 16 on
-64-bit systems. Only rarely is any higher boundary (such as a page
+In @theglibc{}, the block that @code{malloc} gives you is guaranteed
+to be 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}).
@@ -677,6 +678,18 @@ returns a non-null pointer to a newly allocated size-zero block;
other implementations may return @code{NULL} instead.
POSIX and the ISO C standard allow both behaviors.
+@item
+In @theglibc{}, a non-null pointer returned by @code{malloc (@var{size})}
+is a multiple of @code{alignof (max_align_t)} when converted to an integer.
+Other implementations may align the result only to what is needed for
+fundamentally-aligned objects of size at most @code{max (@var{size}, 1)}.
+For example, if @code{alignof (max_align_t)} is 16 but smaller
+fundamentally-aligned objects all have alignment of at most 4,
+other implementations of @code{malloc (15)} might return
+a pointer that is a multiple of 4 but not of 16 or even of 8.
+Portable code should therefore use a function like @code{aligned_alloc}
+if it needs @code{alignof (max_align_t)} alignment even for small allocations.
+
@item
In @theglibc{}, a failed @code{malloc} call sets @code{errno},
but ISO C does not require this and non-POSIX implementations
@@ -866,6 +879,10 @@ Otherwise, if @var{newsize} is zero
Otherwise, if @code{realloc} cannot reallocate the requested size
it returns @code{NULL} and sets @code{errno}; the original block
is left undisturbed.
+
+Any non-null pointer returned by @code{realloc} satisfies the same
+alignment restrictions as a similar pointer returned by @code{malloc}
+with the same size.
@end deftypefun
@deftypefun {void *} reallocarray (void *@var{ptr}, size_t @var{nmemb}, size_t @var{size})
@@ -980,6 +997,12 @@ is declared in @file{stdlib.h}.
This function allocates a block long enough to contain a vector of
@var{count} elements, each of size @var{eltsize}. Its contents are
cleared to zero before @code{calloc} returns.
+
+In @theglibc{}, the vector is aligned the same way that @code{malloc}
+aligns its returned values. In other implementations, it is merely
+aligned suitably for any array of fundamentally-aligned elements each
+with size at most @code{max (@var{size}, 1)}.
+
@end deftypefun
You could define @code{calloc} as follows:
--
2.51.0
next prev parent reply other threads:[~2026-02-12 18:20 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-12 18:18 [PATCH v3 0/4] malloc doc fixes for alignment Paul Eggert
2026-02-12 18:18 ` [PATCH v3 1/4] Document max_align_t Paul Eggert
2026-02-26 12:41 ` Florian Weimer
2026-02-12 18:18 ` Paul Eggert [this message]
2026-02-26 12:53 ` [PATCH v3 2/4] Document malloc alignment Florian Weimer
2026-02-26 12:56 ` Florian Weimer
2026-02-26 13:17 ` Florian Weimer
2026-02-12 18:18 ` [PATCH v3 3/4] Say malloc (0) != NULL is now common; resection Paul Eggert
2026-02-26 13:15 ` Florian Weimer
2026-02-12 18:18 ` [PATCH v3 4/4] malloc: alignment might change in future versions Paul Eggert
2026-02-26 12:47 ` Florian Weimer
2026-02-26 18:41 ` Paul Eggert
2026-02-26 18:38 ` [PATCH 1/2] doc: document max_align_t effect on ABI Paul Eggert
2026-02-26 18:38 ` [PATCH 2/2] doc: document C23 changes to intmax_t Paul Eggert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260212182031.107003-3-eggert@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=libc-alpha@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).