3 ms·

> Wrap around is one of the leading causes of security issues in all software. A wrap around on its own can not cause unsafety in rust, only panics. As in, ma

> Wrap around is one of the leading causes of security issues in all software. A wrap around on its own can not cause unsafety in rust, only panics. As in, maybe you try to use the wrapped integer as an array index, that's still safe even if it wraps (because Rust bounds checks). It would only case memory safety when used alongside code in an unsafe block. > The author says that it is very hard not easy to exploit C libraries loaded by Python. I drew a different conclusion from that section

bjourne 8y ago
> A wrap around on its own can not cause unsafety in rust, only panics. You are either misinformed or do not know what safety means. Integer types in Rust in release mode wraps around and that can lead to consequences much worse than crashing. Programs doing the exact opposite of what they were intended to. Now I see that you are talking about MEMORY safety which I'm not. Writing safe programs includes so much more than just memory safety. > I drew a different conclusion from that section I have not seen a single CVE about the issue.
- staticassertion 8y ago
  > Now I see that you are talking about MEMORY safety which I'm not. Writing safe programs includes so much more than just memory safety. Yes, what rust claims is memory safety, not safety from all forms of bugs. If you don't want wrapping integers, you can compile with a flag to panic on overflow, or use types in std that will have the behavior you want. > I have not seen a single CVE about the issue. That's part of the point of the article. CVEs are rarely filed for memory safety issues in the underlying C libraries that make up the Python ecosystem.
  - bjourne 8y ago
    > Yes, what rust claims is memory safety, not safety from all forms of bugs. If you don't want wrapping integers, you can compile with a flag to panic on overflow, or use types in std that will have the behavior you want. Which was the point! High level languages have many more safety features than Rust have, such as non-wrapping integers. Trading those features for performance is foolish. Claiming Rust or any other low-level language is on an "equal footing" with Python or any other high-level language because you have this and that feature is facetious. In C you can write your own types with bounds checking and even your own garbage collector to make your programs memory safe. Using dumb arguments like these we can claim C is as safe as Python. But the arguments are dumb because that is not how programs are written in the real world. In the same way, claiming Rust is as safe as Python because it has a flag (that no one uses because it makes your programs twice as slow!) to perform wrap around checking and types in the standard library with correct behavior is dumb. It is what happens IN PRACTICE that matters.
    - burntsushi 8y ago
      > It is what happens IN PRACTICE that matters. Funny you should say that, because when you compile Rust programs in debug mode (e.g., how most tests are run), then overflow results in a panic. This isn't foolproof, but that's what "in practice" means. For me, overflow bugs tend to be caught in tests. You're getting too hung up on one specific point (integer wrapping) and being too bombastic about it. Consider other facets of safety such as exception safety, data races and ownership.

bjourne 8y ago

> A wrap around on its own can not cause unsafety in rust, only panics. You are either misinformed or do not know what safety means. Integer types in Rust in release mode wraps around and that can lead to consequences much worse than crashing. Programs doing the exact opposite of what they were intended to. Now I see that you are talking about MEMORY safety which I'm not. Writing safe programs includes so much more than just memory safety. > I drew a different conclusion from that section I have not seen a single CVE about the issue.

staticassertion 8y ago
> Now I see that you are talking about MEMORY safety which I'm not. Writing safe programs includes so much more than just memory safety. Yes, what rust claims is memory safety, not safety from all forms of bugs. If you don't want wrapping integers, you can compile with a flag to panic on overflow, or use types in std that will have the behavior you want. > I have not seen a single CVE about the issue. That's part of the point of the article. CVEs are rarely filed for memory safety issues in the underlying C libraries that make up the Python ecosystem.
- bjourne 8y ago
  > Yes, what rust claims is memory safety, not safety from all forms of bugs. If you don't want wrapping integers, you can compile with a flag to panic on overflow, or use types in std that will have the behavior you want. Which was the point! High level languages have many more safety features than Rust have, such as non-wrapping integers. Trading those features for performance is foolish. Claiming Rust or any other low-level language is on an "equal footing" with Python or any other high-level language because you have this and that feature is facetious. In C you can write your own types with bounds checking and even your own garbage collector to make your programs memory safe. Using dumb arguments like these we can claim C is as safe as Python. But the arguments are dumb because that is not how programs are written in the real world. In the same way, claiming Rust is as safe as Python because it has a flag (that no one uses because it makes your programs twice as slow!) to perform wrap around checking and types in the standard library with correct behavior is dumb. It is what happens IN PRACTICE that matters.
  - burntsushi 8y ago
    > It is what happens IN PRACTICE that matters. Funny you should say that, because when you compile Rust programs in debug mode (e.g., how most tests are run), then overflow results in a panic. This isn't foolproof, but that's what "in practice" means. For me, overflow bugs tend to be caught in tests. You're getting too hung up on one specific point (integer wrapping) and being too bombastic about it. Consider other facets of safety such as exception safety, data races and ownership.