vec::consume/consume_mut are probably not failsafe.

[brson]

Code looks like this:

fn consume<T>(+v: ~[T], f: fn(uint, +v: T)) unsafe {                                                                                                                          
    do as_imm_buf(v) |p, ln| {                                                                                                                                                
        for uint::range(0, ln) |i| {                                                                                                                                          
            let x <- *ptr::offset(p, i);                                                                                                                                      
            f(i, move x);                                                                                                                                                     
        }                                                                                                                                                                     
    }                                                                                                                                                                         

    raw::set_len(v, 0);                                                                                                                                                       
}         

What happens if the callback fails in the middle of the loop?

[nikomatsakis]

So, I think it's ok today---each item that is moved will be zero'd. However, it's an important consideration if we ever wanted to stop zeroing out things to indicate that they have been moved (which I do).

[brson]

I thought that might be the situation. Deserves a test case.

[nikomatsakis]

Indeed!

[brson]

I added failure tests for most of the higher-order vec functions and they all passed. Yay.

[brson]

This is still not correct. Even though it doesn't crash a failure leaves the vector filled with nulls pretending to be valid elements (set_len never gets called). I will revisit this later.

[brson]

Argh! but the frame owns the vector so it's not possible to be referred to anywhere else. This is why we are writing a safe language.

[jruderman]

Do T's destructors get called the correct number of times?

[brson]

@jruderman I am not sure. Built in destructors definitely do, but I did not test with user-defined dtors.

[bstrie]

Here's how vec::consume looks today:

pub fn consume<T>(mut v: ~[T], f: &fn(uint, v: T)) {
    unsafe {
        do as_mut_buf(v) |p, ln| {
            for uint::range(0, ln) |i| {
                // NB: This unsafe operation counts on init writing 0s to the
                // holes we create in the vector. That ensures that, if the
                // iterator fails then we won't try to clean up the consumed
                // elements during unwinding
                let x = intrinsics::init();
                let p = ptr::mut_offset(p, i);
                f(i, util::replace_ptr(p, x));
            }
        }

        raw::set_len(&mut v, 0);
    }
}

That comment seems somewhat reassuring, but someone more qualified ought to determine if that means this issue is resolved.

[thestinger]

We don't have catchable exceptions so it's safe. It always zeroes the drop flag for custom destructors.