You can break memory safety in a single thread if you allow multiple
mutable references to the same object. Consider an enum like this:
enum Foo {
Pointer(Box<T>),
Integer(i32)
}
Take one reference to the boxed `T` inside a `Foo` of the `Pointer`
variant. It doesn't even have to be mutable. Then use a mutable reference
to the enum object itself to change the variant to `Integer`. Reading from
the first reference now is a use-after-free, since the boxed T was freed
when the variant changed. If you'd taken a reference to the box instead,
you'd be trying to follow a garbage pointer.
2014-09-19 17:32 GMT+02:00 Clark Gaebel <cg.wowus...@gmail.com>:
> You can use a Vec> for this.
> —
> Sent from Mailbox <https://www.dropbox.com/mailbox>
>
>
> On Fri, Sep 19, 2014 at 1:14 AM, Manish Goregaokar <manishsm...@gmail.com>
> wrote:
>
>> Iterator invalidation is a common memory safety issue where you have two
>> references being simultaneously used -- one mutable, one immutable. With
>> multiple mutable references worse errors can happen.
>>
>> -Manish Goregaokar
>>
>> On Fri, Sep 19, 2014 at 1:09 PM, silvio <silvio.fris...@gmail.com> wrote:
>>
>>> Hi Rust,
>>>
>>> I've recently tried to investigate rust's claim of being fast and had a
>>> look at debian shootout.
>>>
>>> A particular program I took a looked at is the n-body problem in which
>>> you have to loop over pairs of bodies to calculate their gravitational
>>> attraction. What struck me as strange was the number of indexing
>>> operations.
>>>
>>> bodies[i]
>>> bodies[j]
>>> bodies[i]
>>> bodies[j]
>>> ...
>>>
>>> Now I don't know if the compiler is smart enough to optimize this away.
>>> However, it seems generally impossible to make references.
>>>
>>> let mut body_i = bodies.someMethod(i)
>>> let mut body_j = bodies.someMethod(j)
>>>
>>> So how is this usually done?
>>>
>>> Why are multiple mutable references to the same object not allowed. To
>>> achieve safe memory you only need to guarantee that different threads
>>> don't write/read from/to the same memory location at the same time and
>>> that is handled via ownership. (borrowed) references & don't have
>>> ownership. Additionally, you need to ensure that all references not only
>>> mut are not usable anymore until you can transfer ownership. So, I don't
>>> understand why mut and not mut are treated differently.
>>>
>>> An other small thing. I read that you should always return a type
>>> directly.
>>>
>>> fn foo(args) -> big_struct
>>>
>>> Does this mean that all return values are secretly pointers passed to
>>> the function except for things that fit into registers?
>>>
>>>
>>> regards
>>>
>>> silvio
>>> _______________________________________________
>>> Rust-dev mailing list
>>> Rust-dev@mozilla.org
>>> https://mail.mozilla.org/listinfo/rust-dev
>>>
>>
>>
>
> _______________________________________________
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
