[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z9k7cwE5UNOIyoXR@google.com>
Date: Tue, 18 Mar 2025 09:22:59 +0000
From: Alice Ryhl <aliceryhl@...gle.com>
To: Tamir Duberstein <tamird@...il.com>
Cc: Benno Lossin <benno.lossin@...ton.me>, Danilo Krummrich <dakr@...nel.org>,
Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>,
Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
"Björn Roy Baron" <bjorn3_gh@...tonmail.com>, Andreas Hindborg <a.hindborg@...nel.org>,
Trevor Gross <tmgross@...ch.edu>, rust-for-linux@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] rust: alloc: use `spare_capacity_mut` to reduce unsafe
On Mon, Mar 17, 2025 at 01:55:18PM -0400, Tamir Duberstein wrote:
> > >
> > > fn dec_len(&mut self, count: usize) -> &mut [T] {
> > > self.len = self.len.saturating_sub(count);
> > >
> > > // Potentially broken, since maybe `count > self.len`, hence need an
> > > // additional check.
> > > unsafe { slice::from_raw_parts_mut(self.as_mut_ptr().add(self.len), count) }
> > > }
> >
> > Ah sorry, in my mental model the function returned `()`. Do we need the
> > return value?
>
> The return value is the whole genesis of `dec_len`, we want to return
> something to let the caller know they need to drop or copy the memory.
Hold on .. it returns &mut [T]. You're usually not allowed to take
ownership of or drop values behind a mutable reference.
Alice
Powered by blists - more mailing lists