> 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...
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...
Also, in C++ containers, ".at()" is usually checked, but "[]" is not. So C++ code still regularly has buffer overflow problems.
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.
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-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.
But until then, Rust's approach is runtime bounds checking.
As does C++. See e.g. vector.at and libstdc++ debug mode:
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.