Possible unsound unsafe code

⚓ Rust 📅 2026-01-23 👤 surdeus 👁️ 11

Warning

This post was published 47 days ago. The information described in this article may have changed.

Info

This post is auto-generated from RSS feed The Rust Programming Language Forum - Latest topics. Source: Possible unsound unsafe code

I haven't worked on Rust for some time, I got a issue raised with a crate, and would like an opinion, see

github.com/georgebarwood/btree_experiment

Potential unsoundness

opened 04:07PM - 17 Jan 26 UTC

xizheyin

Hello, thank you for your crate. I discovered a potential unsoundness using a st…atic analysis tool. However, I noticed that this doesn't seem to be exposed as a pub function, so I'm not sure. The `get` method of `ShortVec` copies the ownership of the object pointed to by `p`, which is dangerous for non-Copy types. This `next` method calls `ShortVec::get`, causing elements in `v` to have two owners—the element itself and the returned value. This violates Rust's safety constraints. If `v`'s elements are non-Copy, it may lead to issues in safe code like double drops and use-after-free. Similarly, `ShortVec::drop` appears to have a comparable problem. ``` impl<T> Iterator for IntoIterShortVec<T> { type Item = T; #[inline] fn next(&mut self) -> Option<Self::Item> { if self.start == self.v.len() { None } else { let ix = self.start; self.start += 1; Some(unsafe { self.v.v.get(ix) }) } } } ``` ``` impl<T> Drop for ShortVec<T> { fn drop(&mut self) { let mut len = self.len as usize; while len > 0 { len -= 1; unsafe { self.v.get(len); } } self.len = 0; self.set_alloc(0); } } ```

4 posts - 4 participants

Read full topic

🏷️ Rust_feed

👍 󠁮󠁮󠁮󠁮 👎 󠁮󠁮󠁮󠁮