Prohibit Vec::set_len beyond capacity

[stepancheg]

Vec::set_len operation is useful for I/O (reading into uninitialized
memory), however it is too easy to corrupt memory by setting length
larger than capacity.

On the other hand, setting length larger than capacity is almost useless
in practice.

So set_len should not allow to set length larger than capacity.

[thestinger]

It's not really much safer with this check and it's going to add a lot of overhead to some of the algorithms where this is performed in a loop. It's memory unsafe just to extend the length past the initialized data because of the semantics of undefined data in LLVM.

[stepancheg]

Range check in set_len makes this code safe:

let mut buf: Vec<u8> = Vec::with_capacity(10000);
buf.set_len(100000); // <-- hard to spot problem is here
file.read_into(buf.as_mut_slice());
return buf;

[alexcrichton]

Note that this does not change from_raw_parts, which would have the two methods be inconsistent.

[thestinger]

@stepancheg: That example would be memory safe. It would often leave uninitialized data at the end of the vector included in the length. In reasonable code the length would be in a constant rather than a repeated magic number, although here it would really be set based on the number of bytes read.

If there's going to be a check in set_len, then we need an unchecked version too. The overhead of unnecessary branches and failure needs to be avoided in performance critical code. Any function calling set_len is now impure due to unwinding.

[stepancheg]

@alexcrichton I'm unsure about from_raw_parts, because if assertion in from_raw_parts fails, memory is leaked.

[lilyball]

set_len() is already an unsafe function that exposes uninitialized memory. I don't think adding an assertion makes it really any safer, and instead just serves as a way to slow down existing code that uses this method.

[alexcrichton]

Closing due to inactivity. It sounds like this may not be desired, but feel free to reopen if you'd like to.