5 ms·

> Rust [...] eliminates entire classes of bugs, such as off-by-one errors [...]. How so? OBO is a logic error isn't it?

pas 4y ago
Iterators all the way down, maybe some const generics, who knows? :)
eldenring 4y ago
Not 100% sure what they mean, but a lot of the api choices really try to make indexing decisions explicit. ex: Bounds::Excluded and iterators like the other commenter mentioned.
efficax 4y ago
Rust gaurantees (except in unsafe code) that off-by-one errors will never lead to reading or writing from outside of safe memory bounds. You can still call `unwrap` on a out-of-bounds vector index and get a panic (panics are considered safe since they are memory safe), although you should not be using unwrap in ways that can panic in production code.
atty 4y ago
It can’t stop me from accessing index 1 when I meant 0 on a 3d array, so I think the claim doesn’t make much sense. Rust can stop me from accessing index N+1 though, which is useful for security. Of course almost every language also has support for bounds checked arrays either in their core or their standard library, and some for of array iterators, so I don’t think that’s a particularly compelling reason to choose Rust.
- cmeacham98 4y ago
  What are the bounds checked arrays in C's or C++'s standard library?
  - haolez 4y ago
    You can enable bound checking when calling the compiler. I don't remember the actual command line flags, though.
    - cmeacham98 4y ago
      A non-standard compiler feature is not "their core or their standard library".
      - pjmlp 4y ago
        The ISO standard requires at() to be checked, while it leaves for implementations the freedom to decide if operator[]() is checked or not. As such, checks for operator[]() are usually only enabled in debug builds, although Android and Red-Hat ship with them enabled into production. Additionally, before C++ got a standard library, the frameworks that were shipped alongside compilers always had those checks enabled by default.
        ablatner 4y ago
        std::vector, with dynamic memory allocation, is not necessarily safe for embedded applications. It seems like Rust provides bounds checks at a primitive level.
        cmeacham98 4y ago
        I'll admit I don't have the stats in front of me, but I can practically for guarantee code using std::vector in the wild that [] usage outnumbers .at() usage, probably at least 10 (or even 100) to 1. C also doesn't have .at(). Considering C and C++ are the most obvious and direct competitors to Rust, bounds checking would be a significant upgrade if Rust paradigms cause it to be used more often.
        pjmlp 4y ago
        It does, but as I mentioned, Red-Hat and Android ship with bounds checking enabled via FORTIFY. C was already a bad option in the mid-90's compared with the alternatives, it is due to the unfortunate adoption of GNU manifesto and POSIX systems that we got where we are. Hence why the ultimate solution is to have hardware memory tagging for bounds checking, Solaris has been doing it for a decade, ARM is following along, including a collaboration with CHERI, only Intel borked their MPX design, and it seems not to be on RISC-V's radar. Note that while defaults matter, and given the option one should rather use a safe systems language, if there are ways to do unbound accesses, there will always be some folks going that route because reasons.

pas 4y ago

Iterators all the way down, maybe some const generics, who knows? :)

Not 100% sure what they mean, but a lot of the api choices really try to make indexing decisions explicit. ex: Bounds::Excluded and iterators like the other commenter mentioned.

efficax 4y ago

Rust gaurantees (except in unsafe code) that off-by-one errors will never lead to reading or writing from outside of safe memory bounds. You can still call `unwrap` on a out-of-bounds vector index and get a panic (panics are considered safe since they are memory safe), although you should not be using unwrap in ways that can panic in production code.

atty 4y ago

It can’t stop me from accessing index 1 when I meant 0 on a 3d array, so I think the claim doesn’t make much sense. Rust can stop me from accessing index N+1 though, which is useful for security. Of course almost every language also has support for bounds checked arrays either in their core or their standard library, and some for of array iterators, so I don’t think that’s a particularly compelling reason to choose Rust.

cmeacham98 4y ago
What are the bounds checked arrays in C's or C++'s standard library?
- haolez 4y ago
  You can enable bound checking when calling the compiler. I don't remember the actual command line flags, though.
  - cmeacham98 4y ago
    A non-standard compiler feature is not "their core or their standard library".
    - pjmlp 4y ago
      The ISO standard requires at() to be checked, while it leaves for implementations the freedom to decide if operator[]() is checked or not. As such, checks for operator[]() are usually only enabled in debug builds, although Android and Red-Hat ship with them enabled into production. Additionally, before C++ got a standard library, the frameworks that were shipped alongside compilers always had those checks enabled by default.
      - ablatner 4y ago
        std::vector, with dynamic memory allocation, is not necessarily safe for embedded applications. It seems like Rust provides bounds checks at a primitive level.
      - cmeacham98 4y ago
        I'll admit I don't have the stats in front of me, but I can practically for guarantee code using std::vector in the wild that [] usage outnumbers .at() usage, probably at least 10 (or even 100) to 1. C also doesn't have .at(). Considering C and C++ are the most obvious and direct competitors to Rust, bounds checking would be a significant upgrade if Rust paradigms cause it to be used more often.
        pjmlp 4y ago
        It does, but as I mentioned, Red-Hat and Android ship with bounds checking enabled via FORTIFY. C was already a bad option in the mid-90's compared with the alternatives, it is due to the unfortunate adoption of GNU manifesto and POSIX systems that we got where we are. Hence why the ultimate solution is to have hardware memory tagging for bounds checking, Solaris has been doing it for a decade, ARM is following along, including a collaboration with CHERI, only Intel borked their MPX design, and it seems not to be on RISC-V's radar. Note that while defaults matter, and given the option one should rather use a safe systems language, if there are ways to do unbound accesses, there will always be some folks going that route because reasons.