4 ms·
> Your C program is free to define x as an array with four elements and then access x[6] anyway - but Rust deliberately cannot do that. Not in Safe Rust, but al
by drran 5y ago
> Your C program is free to define x as an array with four elements and then access x[6] anyway - but Rust deliberately cannot do that. Not in Safe Rust, but also not in Unsafe Rust either.
Woot?
fn main() {
let a = [0, 1, 2];
let _b = [42, 42, 42];
println!("{}", unsafe{a.get_unchecked(6)});
}
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=250da57d35baaed223d43c73dced8b0c https://play.rust-lang.org/?version=stable&mode=debug&editio...
- deleted 5y ago[deleted]
- Arnavion 5y agoThe claim was about `x[6]`, which does not appear in your program. The point is that `[]` is always bounds-checked, and the bounds-checking cannot be opted out of even with `unsafe`.
- fnord123 5y ago> The claim was about `x[6]`, which does not appear in your program. That was C code. The rust code for that was provided by drran. > The point is that `[]` is always bounds-checked, and the bounds-checking cannot be opted out of even with `unsafe`. I don't think anyone is hung up on whether you use std::ops::Index or not. You can access arrays without bounds checks.
- Arnavion 5y agohttps://news.ycombinator.com/item?id=27941675 https://news.ycombinator.com/item?id=27941675 >No. Unsafe Rust only gets to do three things that aren't related to the "unsafe" keyword itself. >[...] >Your C program is free to define x as an array with four elements and then access x[6] anyway - but Rust deliberately cannot do that. Not in Safe Rust, but also not in Unsafe Rust either. >[...] >In fact by default the Rust compiler would warn you, if you write unsafe { foo[z] = 0; } that unsafe isn't doing anything useful here and you should remove it. That array dereference either is or, if z is small enough, is not, an overflow, and either way unsafe makes no difference.
- pjmlp 5y ago> You can access arrays without bounds checks. By explicitly doing it so, in an operation that is easy to grep for, or in the case of a binary library, search for the symbol during the linking phase. Something that is impossible to validate in C, unless one is using a custom compiler, like Apple is doing for iBoot firmware.
- cesarb 5y ago> By explicitly doing it so, in an operation that is easy to grep for, or in the case of a binary library, search for the symbol during the linking phase. Most of the time, these operations will be inlined, so they will already be gone by the time it gets to the linker. The compiler phase is the latest point where they are still visible.
- pjmlp 5y agoBetter than in C where they are nowhere to be found, not even in source code.
- baq 5y agoholy goalpost batman. you've moved them to the other side of the world. what's next, you can't write 6[x] in rust but it's perfectly fine C, thus rust is inadequate?
- Arnavion 5y agoYou might want to re-read the conversation thread. Hint: I am not tialaramex, and neither of us said anything against Rust in our comments.
- tialaramex 5y agoCalling get_unchecked on this array ends up as get_unchecked on the slice containing that whole array, which ends up as as get_unchecked on the slice index, and in the end it is... Dereferencing a raw pointer. One of the three specific things I said unsafe Rust can in fact do. This is not a "funny syntax" thing, a[6] is the idiomatic and obvious way to express this in Rust, and, it isn't allowed because it's a buffer overflow. Whereas a[6] is also the idiomatic and obvious way to express this in C and the result is Undefined Behaviour.