-
Notifications
You must be signed in to change notification settings - Fork 60
Documentation for mem::forget implies that it may invalidate raw pointers to heap allocations #320
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Actually, this code is unsound under Stacked Borrows: let s = Box::new(32);
let s_ptr = s.as_ptr();
std::mem::forget(s);
let lowercase_e = unsafe { *s_ptr }; That is because passing The example in rust-lang/rust#79320 used The docs recommend using |
That's a lot more to do with Box being an unsafe code hazard than anything else. Wouldn't using |
The mode of use is different though: let s = Box::new(32);
let s = ManuallyDrop::new(s);
let s_ptr = s.as_ptr();
let lowercase_e = unsafe { *s_ptr }; This pattern works fine, and the standard lib uses it quite a bit. |
Ah, the manually drop moves before the pointer getting, right then. |
I think that adding Unique to Vec has dubious optimization value and will probably invalidate a lot of code. I'm happy to gather some data on this if someone can implement the change in Miri or offer guidance on how I could do that. Separately, is there any reason to keep |
|
Isn't the whole point of |
Oh wait, I confused it with |
That requires a big redesign of SB I think -- but one that I want to do anyway since it also helps with some other issues. |
(Transferred from rust-lang/rust#79320 )
Someone pointed out that the documentation for
mem::forget
may be a bit too broad, in that it could be interpreted as saying that heap allocations owned by a value passed tomem::forget
may be invalidated.I think the UCG WG is currently the best group of people to work out precisely what the rules are here, and what the best mental model is, (if you haven't already, that is).
I'm closing rust-lang/rust#79320 because I don't think the work will be tracked usefully in that context.
The text was updated successfully, but these errors were encountered: