All of lore.kernel.org
 help / color / mirror / Atom feed
From: Danilo Krummrich <dakr@kernel.org>
To: Benno Lossin <benno.lossin@proton.me>
Cc: Tamir Duberstein <tamird@gmail.com>,
	ojeda@kernel.org, alex.gaynor@gmail.com, boqun.feng@gmail.com,
	gary@garyguo.net, bjorn3_gh@protonmail.com,
	a.hindborg@kernel.org, aliceryhl@google.com, tmgross@umich.edu,
	andrewjballance@gmail.com, rust-for-linux@vger.kernel.org
Subject: Re: [PATCH 1/2] rust: alloc: extend safety requirements of Vec::set_len()
Date: Sun, 16 Mar 2025 13:31:30 +0100	[thread overview]
Message-ID: <Z9bEosVk8-0sgSbw@pollux> (raw)
In-Reply-To: <D8HL95D099MI.2N779RERY6DAE@proton.me>

On Sun, Mar 16, 2025 at 09:38:23AM +0000, Benno Lossin wrote:
> On Sun Mar 16, 2025 at 1:33 AM CET, Tamir Duberstein wrote:
> > On Sat, Mar 15, 2025 at 2:36 PM Danilo Krummrich <dakr@kernel.org> wrote:
> >>
> >> On Sat, Mar 15, 2025 at 05:44:29PM +0000, Benno Lossin wrote:
> >> >
> >> > What is meant by "copied"? I agree with Tamir, this can probably just be
> >> > "taken ownership of".
> >>
> >> If not dropped in place, the only way to take ownership of the object is to copy
> >> the corresponding memory, i.e. the caller can not take ownership of the object
> >> at its current memory location, since this memory is owned by the vector.
> >
> > I think this is the point I was trying to make: the language semantics
> > are such that "taking ownership of" is equivalent to "become
> > responsible for the dropping of", so it doesn't make sense to write
> > that here, as though this requirement is specific to the semantics of
> > this function.
> >
> >> AFAIU, when we speak of ownership, we mean ownership over a value or object, but
> >> not ownership over the underlying memory.
> >>
> >> Hence, I think it's important to mention that it needs to be either dropped in
> >> place or copied in order to take ownership.
> >>
> >> Even if we agree that "drop in place" is considered as "take ownership", we need
> >> to differentiate between the special case of taking ownership where its dropped
> >> in place and the requirement to copy the value and then take ownership.
> 
> I get where you're coming from, but I wouldn't call that copying a
> value. Copying for me means that there would be two instances of the
> same object. But since the one in `[new_len, len)` will get invalidated,
> I don't think that copy makes sense.

What I meant is "copy the memory where the value is stored".

> 
> Also why even is this a safety requirement? There is `mem::forget`, so
> doing `vec.set_len(0)` can also be done by safe code:
> 
>     while let Some(val) = vec.pop() {
>         forget(val);
>     }
> 
> I don't think this needs to be a safety requirement.

Given that mem::forget() is considered safe, you clearly have a point here.

Let's go with just "must be taken ownership of" then. Unless there's subsequent
feedback, I won't send a new version for this, since you both already gave your
(conditional) RB for this.

(I tend to forget that mem::forget() is formally safe, since it can cause all
kinds of bugs, e.g. dead lock the whole machine if called for a lock in the
kernel, etc.)

  reply	other threads:[~2025-03-16 12:31 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-15 15:43 [PATCH 1/2] rust: alloc: extend safety requirements of Vec::set_len() Danilo Krummrich
2025-03-15 15:43 ` [PATCH 2/2] rust: alloc: add missing invariant in Vec::set_len() Danilo Krummrich
2025-03-15 15:52   ` Danilo Krummrich
2025-03-15 17:44   ` Benno Lossin
2025-04-07 12:10   ` Danilo Krummrich
2025-03-15 16:06 ` [PATCH 1/2] rust: alloc: extend safety requirements of Vec::set_len() Tamir Duberstein
2025-03-15 17:44 ` Benno Lossin
2025-03-15 18:36   ` Danilo Krummrich
2025-03-16  0:33     ` Tamir Duberstein
2025-03-16  9:38       ` Benno Lossin
2025-03-16 12:31         ` Danilo Krummrich [this message]
2025-03-16 12:42           ` Tamir Duberstein
2025-03-16 13:01             ` Danilo Krummrich
2025-03-16 13:13               ` Tamir Duberstein
2025-03-16 13:46                 ` Danilo Krummrich
2025-03-16 17:40                   ` Benno Lossin
2025-03-16 18:59                     ` Danilo Krummrich
2025-03-16 19:09                       ` Danilo Krummrich
2025-03-16 19:30                         ` Tamir Duberstein
2025-03-16 20:54                           ` Danilo Krummrich
2025-03-16 21:10                             ` Tamir Duberstein
2025-03-16 21:17                               ` Danilo Krummrich
2025-03-16 21:20                                 ` Tamir Duberstein
2025-03-16 21:52                                   ` Tamir Duberstein
2025-03-16 21:59                                     ` Danilo Krummrich
2025-03-17  9:52                         ` Benno Lossin
2025-03-17 11:12                           ` Danilo Krummrich
2025-03-17 14:57                             ` Benno Lossin
2025-03-17 15:57                               ` Danilo Krummrich
2025-03-17 16:03                                 ` Miguel Ojeda
2025-03-17 17:33                                 ` Benno Lossin
2025-03-17 18:28                                   ` Danilo Krummrich
2025-03-16 12:08       ` Danilo Krummrich
2025-03-17 10:36 ` Alice Ryhl
  -- strict thread matches above, loose matches on Subject: below --
2025-03-17  9:46 Benno Lossin

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=Z9bEosVk8-0sgSbw@pollux \
    --to=dakr@kernel.org \
    --cc=a.hindborg@kernel.org \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=andrewjballance@gmail.com \
    --cc=benno.lossin@proton.me \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=gary@garyguo.net \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tamird@gmail.com \
    --cc=tmgross@umich.edu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.