[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <xn4j14nq63.fsf@greed.delorie.com>
Date: Sat, 08 Feb 2025 15:21:24 -0500
From: DJ Delorie <dj@...hat.com>
To: Alejandro Colomar <alx@...nel.org>
Cc: miguel.ojeda.sandonis@...il.com, eblake@...hat.com, will.newton@...aro.org,
eggert@...ucla.edu, linux-man@...r.kernel.org, dakr@...nel.org,
tamird@...il.com, ojeda@...nel.org, alex.gaynor@...il.com,
boqun.feng@...il.com, gary@...yguo.net, bjorn3_gh@...tonmail.com,
benno.lossin@...ton.me, a.hindborg@...nel.org, aliceryhl@...gle.com,
tmgross@...ch.edu, rust-for-linux@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] rust: alloc: satisfy `aligned_alloc` requirements
Alejandro Colomar <alx@...nel.org> writes:
> - aligned_alloc()
> It makes sure that the input is a power of two, or it fails.
>
> - posix_memalign()
>
> . . . It requires that the input is power of
> two,
>
> I wonder why glibc silently overaligns aligned_alloc() without reporting
> an error for an alignment of 2, while it reports an error for an
> alignment of 3. It doesn't make much sense at first glance. No
> standard seems to require that, so it looks like an arbitrary choice.
Because 2 is a power of two, but 3 isn't. No power of two is a multiple
of 3.
GNU malloc only supports alignments that are powers of two. The
resulting addresses might *happen* to be multiples of other numbers, but
you cannot request that.
As for why, ask Posix:
"If the value of alignment is not a valid alignment supported by the
implementation, a null pointer shall be returned."
[EINVAL]
The value of alignment is not a valid alignment supported by the
implementation."
Powered by blists - more mailing lists