Hey all, I believe I recently had a breakthrough concerning how to think about unsafe code and I tried to prove it to myself by implementing a function that performs a mapping of Vec<T> to Vec<U> without allocating (given equal size and alignment of T and U). So here is my code #![feature(vec_into_…

An ordinary safe assignment to *some_mutable_reference must drop the existing value or it would be a memory leak. So, pointers work the same way.

Note that this behavior used to be in collections. It was dropped for being impractical and insufficiently general to be in the standard library, but not because the implementation was unsound.

Thanks, my test cases were too simple. I only tried it for Vec -> Vec which does not invoke the destructor. When I redid it with Vec<Box> -> Vec<Box>, miri did catch the double free. I've boiled my code down to this now: fn transform_in_place<T, U, F>(v: Vec<T>, mut f: F) -> Vec<U> where F: Fn…

oh cool, did not know that. Rust 1.3. was way before my time with Rust. From what I understand iterators and specializations inside the standard library can achieve the same effect so that the idiomatic v.iter().map(...).collect() pattern can be used instead but I am not sure if that is guaranteed.

It's better practice to call .cast() on pointers instead of as _ because that catches changes in mutability.

[image] geo-ant: Did I miss something else? You now have a memory leak if f panics. That's better than being UB, of course, but probably still not what you want. The usual way to fix this is a guard that cleans up on drop which you forget once you've done all the work you need to do. Somet…

[image] geo-ant: From what I understand iterators and specializations inside the standard library can achieve the same effect so that the idiomatic v.iter().map(...).collect() pattern can be used instead It’s only for .into_iter(), but otherwise, yes, as far as I’m aware that will predictably…

oh wow, great point. I always forget panic safety... and I had to think about what you meant by "leaking memory from the vec itself"... wow this is all really complicated :smiley: I'll update my code accordingly.

[image] geo-ant: wow this is all really complicated :smiley: If you haven't been through it yet, be sure to read through the nomicon chapter about implementing Vec. It has lots of techniques in it for using type to get the compiler to help you remember to do things like this, such as the one…

thank you kindly, I haven't had time to tackle it yet. Will give it a read :slight_smile:

Is My Highly Unsafe Code Correct? In Place Mapping a Vector

code review

H2CO3 July 20, 2023, 4:31pm 19

Yes.

No. &mut [T] coerces to *mut [T]. Rust is not C. Types matter.

Topic		Replies	Views
Safe to transmute lifetimes inside Vec?	20	804	February 7, 2025
Unsafe Rust is... tough? help	10	2911	September 28, 2020
How to cache a vector's capacity? help	59	2923	May 31, 2023
Review of unsafe usage code review	23	1421	June 25, 2021
Why is Vec implemented un-safely? help	26	9883	August 29, 2015

Is My Highly Unsafe Code Correct? In Place Mapping a Vector

Related topics