5 ms·

Very little Rust code actually does all the safety checks that you would expect a debug build of that same program to do, especially in the kernel. You can wri

Very little Rust code actually does all the safety checks that you would expect a debug build of that same program to do, especially in the kernel. You can write safe rust (check the Option<T> returned by vec.get(i)) but code like `p[0] = update_prob(d[0].into(), p[0].into()) as u8;` (https://gitlab.collabora.com/dwlsalmeida/for-upstream/-/commit/7681609641fb9c94a0b5d827dc2e7290401689c3#eef62635f4a18e96131ace643dc5dcb1dde2fbb5_0_1645 https://gitlab.collabora.com/dwlsalmeida/for-upstream/-/comm...) can panic at three different places. Such a panic would become a kernel oops, which wouldn't be the end of the world but it would probably kill whatever program was trying to decode video. With additional optimisation options, the bounds checking may even be omitted entirely. Rust does generate more accurate bounds checking warnings thanks to all the metadata it has, but that should not be solely relied upon. Rust will let you make those mistakes, but only sometimes, not usually like in old C or C++. I think it's important to know the difference, because feeling invulnerable to these bugs may lead you to write buggy code because you stopped thinking about common C bugs entirely. Also worthy of note is that because of a compiler bug, it's possible to leak memory and cause other weird memory bugs in perfectly safe Rust at the moment. It involves messing with lifetimes and semi-unsafe code so I doubt that bug would just sneak in, but the language doesn't make your code completely bullet proof.

KerrAvon 3y ago
> can panic at three different places Remember that some of the point here is that it _will_ reliably kill the program if that happens; in C, you might be silently reading or writing to the wrong address 3 times.
Mateon1 3y ago
The `single_ref` field is a fixed-size array in both of the objects referenced in this line, so this line can't panic, and no bounds checks are involved (since the compiler sees the index < length at compile time and doesn't even need to emit one -- although I think it still does, and it's LLVM that gets rid of it actually) Causing memory leaks is possible in safe Rust even without any arcane invocations, you can construct a cycle of Rc<T> counted objects. There's even a perfectly safe Box::leak in the standard library that gives you a &'static reference to any object by leaking it. Preventing leaks is outside of the scope of Rust's safety system.

KerrAvon 3y ago

> can panic at three different places Remember that some of the point here is that it _will_ reliably kill the program if that happens; in C, you might be silently reading or writing to the wrong address 3 times.

Mateon1 3y ago

The `single_ref` field is a fixed-size array in both of the objects referenced in this line, so this line can't panic, and no bounds checks are involved (since the compiler sees the index < length at compile time and doesn't even need to emit one -- although I think it still does, and it's LLVM that gets rid of it actually) Causing memory leaks is possible in safe Rust even without any arcane invocations, you can construct a cycle of Rc<T> counted objects. There's even a perfectly safe Box::leak in the standard library that gives you a &'static reference to any object by leaking it. Preventing leaks is outside of the scope of Rust's safety system.