* [PATCH] malloc.3: Scale back promises of alignment
@ 2013-10-24 19:42 Greg Price
[not found] ` <20131024194248.GC16996-Kwy/eXMQnt4s05kO6ufOU7g7sE8m1Ewp@public.gmane.org>
0 siblings, 1 reply; 2+ messages in thread
From: Greg Price @ 2013-10-24 19:42 UTC (permalink / raw)
To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w; +Cc: linux-man-u79uwXL29TY76Z2rM5mHXA
It's not true that the return value is suitably aligned for "any
variable"; for example, it's unsuitable for a variable like
float *x __attribute__ ((__vector_size__ (32)));
which requires 32-byte alignment. Types like this are defined in
<avxintrin.h>, and with 16-byte alignment in <emmintrin.h> and
<xmmintrin.h>, so the application programmer need not even know
that a vector_size attribute has been applied.
On an x86 architecture, a program that loads from or stores to a
pointer with this type derived from malloc can crash because GCC
generates an aligned load/store, like MOVDQA.
The C99 standard (TC3, as of N1256) does say the return value is
suitably aligned for "any type of object". The C11 standard (as
of N1570) revises this to any type with "fundamental alignment",
which means an alignment "supported by the implementation in all
contexts", which I suppose tautologically includes aligning
malloc/realloc return values.
The actual behavior of current glibc malloc is to align to the
greater of 2 * sizeof(size_t) and __alignof__ (long double),
which may be one bit greater than this commit promises.
Signed-off-by: Greg Price <price-3s7WtUTddSA@public.gmane.org>
---
man3/malloc.3 | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/man3/malloc.3 b/man3/malloc.3
index 372b503..84d9852 100644
--- a/man3/malloc.3
+++ b/man3/malloc.3
@@ -131,8 +131,8 @@ The
.BR malloc ()
and
.BR calloc ()
-functions return a pointer to the allocated memory
-that is suitably aligned for any kind of variable.
+functions return a pointer to the allocated memory,
+which is suitably aligned for any built-in type.
On error, these functions return NULL.
NULL may also be returned by a successful call to
.BR malloc ()
@@ -154,7 +154,7 @@ function returns no value.
The
.BR realloc ()
function returns a pointer to the newly allocated memory, which is suitably
-aligned for any kind of variable and may be different from
+aligned for any built-in type and may be different from
.IR ptr ,
or NULL if the request fails.
If
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH] malloc.3: Scale back promises of alignment
[not found] ` <20131024194248.GC16996-Kwy/eXMQnt4s05kO6ufOU7g7sE8m1Ewp@public.gmane.org>
@ 2013-10-25 22:17 ` Michael Kerrisk (man-pages)
0 siblings, 0 replies; 2+ messages in thread
From: Michael Kerrisk (man-pages) @ 2013-10-25 22:17 UTC (permalink / raw)
To: Greg Price; +Cc: linux-man-u79uwXL29TY76Z2rM5mHXA
Greg,
On 25.10.2013 08:42, Greg Price wrote:
> It's not true that the return value is suitably aligned for "any
> variable"; for example, it's unsuitable for a variable like
> float *x __attribute__ ((__vector_size__ (32)));
> which requires 32-byte alignment. Types like this are defined in
> <avxintrin.h>, and with 16-byte alignment in <emmintrin.h> and
> <xmmintrin.h>, so the application programmer need not even know
> that a vector_size attribute has been applied.
>
> On an x86 architecture, a program that loads from or stores to a
> pointer with this type derived from malloc can crash because GCC
> generates an aligned load/store, like MOVDQA.
>
> The C99 standard (TC3, as of N1256) does say the return value is
> suitably aligned for "any type of object". The C11 standard (as
> of N1570) revises this to any type with "fundamental alignment",
> which means an alignment "supported by the implementation in all
> contexts", which I suppose tautologically includes aligning
> malloc/realloc return values.
>
> The actual behavior of current glibc malloc is to align to the
> greater of 2 * sizeof(size_t) and __alignof__ (long double),
> which may be one bit greater than this commit promises.
Thanks for the patch and the excellent commit message. I've applied.
Cheers,
Michael
> Signed-off-by: Greg Price <price-3s7WtUTddSA@public.gmane.org>
> ---
> man3/malloc.3 | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/man3/malloc.3 b/man3/malloc.3
> index 372b503..84d9852 100644
> --- a/man3/malloc.3
> +++ b/man3/malloc.3
> @@ -131,8 +131,8 @@ The
> .BR malloc ()
> and
> .BR calloc ()
> -functions return a pointer to the allocated memory
> -that is suitably aligned for any kind of variable.
> +functions return a pointer to the allocated memory,
> +which is suitably aligned for any built-in type.
> On error, these functions return NULL.
> NULL may also be returned by a successful call to
> .BR malloc ()
> @@ -154,7 +154,7 @@ function returns no value.
> The
> .BR realloc ()
> function returns a pointer to the newly allocated memory, which is suitably
> -aligned for any kind of variable and may be different from
> +aligned for any built-in type and may be different from
> .IR ptr ,
> or NULL if the request fails.
> If
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
My next Linux/UNIX system programming course:
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2013-10-25 22:17 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-10-24 19:42 [PATCH] malloc.3: Scale back promises of alignment Greg Price
[not found] ` <20131024194248.GC16996-Kwy/eXMQnt4s05kO6ufOU7g7sE8m1Ewp@public.gmane.org>
2013-10-25 22:17 ` Michael Kerrisk (man-pages)
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 NNTP newsgroup(s).