4 ms·
> And Rust's solution to buffer overflows is the same as every other language — run time bounds checking. Right, because that's the only way to do it? What's w
by wspeirs 11y ago
> And Rust's solution to buffer overflows is the same as every other language — run time bounds checking.
Right, because that's the only way to do it? What's wrong with that?
The point is a language like Rust has built-in bounds checking...
- okasaki 11y agoSo does C++: http://www.cplusplus.com/reference/stdexcept/out_of_range/ http://www.cplusplus.com/reference/stdexcept/out_of_range/
- acconsta 11y ago>The point is a language like Rust has built-in bounds checking... As does C++. See e.g. vector.at and libstdc++ debug mode: https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode.html https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode.h... The difference is only opt-in vs. opt-out. To its credit, Rust provides additional protections against iterator invalidation and dangling pointers, but its approach to buffer overflows is the same.
- Animats 11y agoThe trend is towards optimizing out bounds checks for at least the easy cases, such as FOR loops. Go does this. Rust should, and probably will soon. That tends to get most of the inner loops where it really matters, like a matrix multiply. C++ can't do that because the compiler doesn't know that a template-implemented bounds check is a bounds check. Also, in C++ containers, ".at()" is usually checked, but "[]" is not. So C++ code still regularly has buffer overflow problems.
- logophobia 11y agoRust does optimize iterators, just not random access. You can even turn off the bound checks with get_unchecked, if you really really need unchecked random access.
- steveklabnik 11y ago(and for loops use iterators under the hood)
- pcwalton 11y ago> Go does this. Rust should, and probably will soon. LLVM does optimize these out, and in more cases than Go does. > C++ can't do that because the compiler doesn't know that a template-implemented bounds check is a bounds check. It doesn't need to. SCCP is a very general optimization. GCC and LLVM optimize out bounds checks in more cases than Go can do.
- chriswarbo 11y ago> Right, because that's the only way to do it? What's wrong with that? Maybe the fact that it's wrong? Compile-time bounds checking is such a classic "hello world" example for type checkers that it's become a cliche (eg. https://www.quora.com/What-are-some-good-examples-of-practical-applications-of-dependent-types-BESIDES-vectors https://www.quora.com/What-are-some-good-examples-of-practic... ) Dependent types make zero-overhead bound checking trivial. More recently, less powerful type systems like liquid types have been proposed (because reasons). Zero-overhead bound checking is usually on their feature list, since a) it's ubiquitous b) it's easy.
- acconsta 11y agoGreat! Please implement them in Rust as soon as possible. But until then, Rust's approach is runtime bounds checking.
- chriswarbo 11y agoI don't know about Rust, I've never used it (and I rarely use C). However, I do use dependently typed languages every day, so I was replying to refute the "that's the only way to do it" argument.
- acconsta 11y agoFor... building software? I thought dependent types haven't escaped research languages.