4 ms·

> Rust has bounds-checked and non-bounds-checked array accesses depending on the developer's preference, and so does C++ You're making it sound like these are

> Rust has bounds-checked and non-bounds-checked array accesses depending on the developer's preference, and so does C++ You're making it sound like these are the same, the difference is the defaults Unsafely accessing an element in C++ vec[i] Unsafely accessing an element in Rust unsafe { vec.get_unchecked(i) } One of these is screamingly obvious that something potentially unsafe is happening and should be audited more closely, that's the real difference. The cause of potential memory issues is isolated and searchable in `unsafe` blocks rather than being potentially anywhere

wavemode 3y ago
So the Rust feature is "screaming obviousness"? Your argument is that the advantage of rewriting the module in Rust is that finding array accesses is visually easier? Why not just use grep?
- vlovich123 3y ago
  It's not just that. It's that you can also add `#![forbid(unsafe_code)]` to your crate. Now you know there's 0 potential memory safety issues of any kind. Keep in mind that failed bounds checks are only 1 memory safety possibility for C++. Another common one is UB behavior which abounds all over the place in C++. The only language security issue you have to worry about with safe Rust is that integers overflow by default in release mode which means you need to explicitly annotate summations that could cause a security exploit with `saturating_X`, `checked_add`, or `wrapping_add` depending on what behavior you want when you exceed the integer range bounds. In cases where security by default is more important, setting `overflow-checks` to `true` in the Cargo profile is better - that way you have to explicitly opt-in to wrapping behavior if you want more performance in the hot path.
- tubthumper8 3y ago
  I'm not on the V8 team, so can't say why grep didn't find the vulnerabilities. That would perhaps be a good suggestion to make to them!
olliej 3y ago
Well that's just false in this context. vec[i] Is safe in v8, blink, jsc, webkit, etc. Rust has a huge number of benefits over c++, but it hurts your argument if you refuse to acknowledge the actual environment the C++ is being used in and make objectively incorrect statements. It implies a lack of understanding of C++ and sounds like all you're doing is parroting other people's critiques without understanding the core issues, which undermines your message. That said it's still not particularly relevant here, because the issues being presented are bugs in the runtime. e.g. the runtime logic and state results in erroneous behavior. The bugs being discussed are not "you did not use a safe vec" or "you did not use Rc", it's "the size or bounds check in vec is incorrect" or "the ref counting in Rc is incorrect". Rust does not inherently stop those the runtime from having bugs, it simply statically limits where the exposure to unsafe operations can occur. That's super relevant to program safety, but it's not relevant to safety in the JS VM runtime, where they're performing the operations that would be unsafe{} in rust as well.

wavemode 3y ago

So the Rust feature is "screaming obviousness"? Your argument is that the advantage of rewriting the module in Rust is that finding array accesses is visually easier? Why not just use grep?

vlovich123 3y ago
It's not just that. It's that you can also add `#![forbid(unsafe_code)]` to your crate. Now you know there's 0 potential memory safety issues of any kind. Keep in mind that failed bounds checks are only 1 memory safety possibility for C++. Another common one is UB behavior which abounds all over the place in C++. The only language security issue you have to worry about with safe Rust is that integers overflow by default in release mode which means you need to explicitly annotate summations that could cause a security exploit with `saturating_X`, `checked_add`, or `wrapping_add` depending on what behavior you want when you exceed the integer range bounds. In cases where security by default is more important, setting `overflow-checks` to `true` in the Cargo profile is better - that way you have to explicitly opt-in to wrapping behavior if you want more performance in the hot path.
tubthumper8 3y ago
I'm not on the V8 team, so can't say why grep didn't find the vulnerabilities. That would perhaps be a good suggestion to make to them!

olliej 3y ago

Well that's just false in this context. vec[i] Is safe in v8, blink, jsc, webkit, etc. Rust has a huge number of benefits over c++, but it hurts your argument if you refuse to acknowledge the actual environment the C++ is being used in and make objectively incorrect statements. It implies a lack of understanding of C++ and sounds like all you're doing is parroting other people's critiques without understanding the core issues, which undermines your message. That said it's still not particularly relevant here, because the issues being presented are bugs in the runtime. e.g. the runtime logic and state results in erroneous behavior. The bugs being discussed are not "you did not use a safe vec" or "you did not use Rc", it's "the size or bounds check in vec is incorrect" or "the ref counting in Rc is incorrect". Rust does not inherently stop those the runtime from having bugs, it simply statically limits where the exposure to unsafe operations can occur. That's super relevant to program safety, but it's not relevant to safety in the JS VM runtime, where they're performing the operations that would be unsafe{} in rust as well.