Re: [PATCH 1/2] rust: alloc: extend safety requirements of Vec::set_len()

[Danilo Krummrich <dakr@kernel.org>]

On Mon, Mar 17, 2025 at 09:52:07AM +0000, Benno Lossin wrote:
> On Sun Mar 16, 2025 at 8:09 PM CET, Danilo Krummrich wrote:
> > On Sun, Mar 16, 2025 at 07:59:34PM +0100, Danilo Krummrich wrote:
> >> But let's define it then; what about:
> >> 
> >> "[`Vec::set_len`] takes (or kepps) ownership of all elements within the range
> >> [0; `new_len`] and abandons ownership of all values outside of this range, if
> >> any."
> >> 
> >> The caller may take ownership of the abandoned elements."
> >> 
> >> I'd argue that giving up ownership, while offering someone else to take it means
> >> that it implies that otherwise we'll just end up forgetting about the value.
> >
> > Btw. I'd still prefer if we could enforce that the caller has to document what
> > should happen to the abandoned value. But I acknowledge that the safety comment
> > isn't the scope for it.
> >
> > It'd be great if e.g. clippy would give us a tool to do something analogous to
> > safety comments.
> >
> > It think it would be useful to enfoce some additional safety documentation. For
> > instance, I think the kernel would much benefit if we could enforce that
> > mem::forget() must be justified with a comment, since as mentioned ina previous
> > mail, it can cause fatal bugs, for instance when used on lock guards.
> 
> I get where you're coming from, but this probably will very quickly get
> out of hand.
> 
> For example, I can define `forget` safely:
> 
>     fn forget<T>(value: T) {
>         struct Cycle<T> {
>             this: RefCell<Option<Arc<Self>>>,
>             value: T,
>         }
>         let cycle = Arc::new(Cycle { this: RefCell::new(None), value });
>         *cycle.this.borrow_mut() = Some(cycle.clone());
>     }
> 
> How would you ensure that this kind of pattern doesn't get written
> accidentally (or with many indirections)?

I don't think that the possibility of writing safe (but yet buggy) code is an
argument against having the possibility of enforcing that a caller must write a
comment for justification on certain things, such as mem::forget().

But there's another reason I think having something like this could be
problematic: It might set the wrong incentive, as in "hey, I can just use a
"sanity requirement" in my function rather figuring out how to ensure it through
the type system, etc.".