> I'd settle for the ability to say: update_in_place(foo.owned_pointer, &fn(~T)
> -> ~T) - surely this would be safe?
That would interact with Drop in a way that could cause a memory violation
after a task failure. The problem is that if you allow a moved value to be
destroyed before something else is swapped into an owned pointer, the task
could fail before the new value got put back in. Then a drop function could
try to access the destroyed value during unwind. Depending on how owned boxes
work, it still might try to free the memory twice, even if Drop was not
implemented.
An illustration--if the update_in_place function existed, this code would
violate memory safety without an "unsafe":
use std::cast;
fn move_out<T>(x:~T) {
// do stuff with x...or not--either way, we're not returning it out, so x is
// destroyed at the end of this function
}
struct Bomb {
x:~str
}
impl Drop for Bomb {
fn drop(&self) {
println(x);
}
}
fn violate_memory() {
// If the update_in_place function existed, it could cause a memory
// violation like so:
let mut b = ~Bomb{x: ~"Kaboom"}
do update_in_place(&mut b) |t| {
move_out(t);
// At this point the memory pointed to by the owned pointer b.x is
// destroyed...but nothing else has been put its place! The
// compiler will prevent us from accessing b or t here, but...
fail!();
// The stack will be unwound, and the Bomb's drop function will
// be called. It will attempt to access the owned value that
// was already destroyed.
}
}
On Aug 30, 2013, at 8:58 PM, Oren Ben-Kiki wrote:
> Sigh, I guess it was too good to be true :-(
>
>
> Speaking of which, a secondary problem I encountered when doing this sort of
> thing, is the "Once function" issue listed in
> https://github.com/mozilla/rust/wiki/Doc-under-construction-FAQ.
>
> Wouldn't it be possible to say, for example, that ~fn can only be invoked
> once to resolve this issue?
>
>
> On Sat, Aug 31, 2013 at 3:50 AM, Patrick Walton <[email protected]> wrote:
> On 8/30/13 3:39 PM, Patrick Walton wrote:
> Thoughts? Does this seem useful? Are there soundness issues I didn't
> notice?
>
> Brian pointed out a massive soundness hole in this, unfortunately. The
> problem is that you can read from the original locations; the right to read
> is not "shut off" during the borrow. I think the fix would have to be to
> replace this with some sort of "generalized swap" operation.
>
>
> Patrick
>
> _______________________________________________
> Rust-dev mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/rust-dev
>
> _______________________________________________
> Rust-dev mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
