Hacker News Reader

Comment by drran | Hacker News Reader

> 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&editio...

View on HN

Calling 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.

The 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`.

> 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.

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.

> 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.

> 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.

Better than in C where they are nowhere to be found, not even in source code.

holy 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?

You might want to re-read the conversation thread.

Hint: I am not tialaramex, and neither of us said anything against Rust in our comments.

Reply on news.ycombinator.com