3 ms·

"All bets are off" is an insane way to characterize this. IF a project is 99.99% safe code and has one unsafe dependency that is a massive difference from a pro

"All bets are off" is an insane way to characterize this. IF a project is 99.99% safe code and has one unsafe dependency that is a massive difference from a project that is 100% unsafe. The surface area of the project that may be vulnerable is going to be relatively tiny. As for an echo chamber, yeah the Rust community downvotes way too much. I find myself upvoting just to counter it. But the downvoted comments here are legitimately bad. Someone being pedantic about the 70%, and being wrong, and another person calling this propaganda.

zozbot234 6y ago
> "All bets are off" is an insane way to characterize this. Well, it depends. If the unsafe{} code is also unsound, then "all bets are off" is quite correct because you can't assume memory safety or lack of UB, even in your own code. In practice, you can use cargo-geiger to warn about crates that internally rely on unsafe code, and cargo-audit will warn about known security issues (including but not limited to unsoundness and memory-unsafety).
- staticassertion 6y ago
  > then "all bets are off" is quite correct because you can't assume memory safety or lack of UB, even in your own code. The problem with "All bets are off" is it's not meaningful. What does that mean? It's so vague. Lots of unsafe code is safe. Lots of UB is not exploitable. I can link to a vulnerable crate and not be vulnerable. Can there be an exploitable bug in rust code? Yeah, sure. But saying "all bets are off" gives the impression of "why even bother if you link to unsafe code", which is absurd. Yeah, we should strive for more safe code, audit unsafe code, be very cautious about using it, but "all bets are off" come on.
  - saagarjha 6y ago
    Well, there's two interpretations of "all bets are off". One is the runtime one, which is if you have a bug in unsafe code, then it is possible that all the other code in your program is safe but you're still totally out of luck because it can invalidate every guarantee. However, from an auditing perspective, the only code you need to look at for memory safety issues is that particular snippet, so you're in a much better position from that perspective.
  - nilkn 6y ago
    > Lots of unsafe code is safe. This seems like a weird statement to make to me when defending Rust simultaneously. The whole selling point of Rust is that it's supposed to let you write provably safe code. When "unsafe" is used, what you're writing can no longer be proven as safe by the compiler. Maybe you've convinced yourself it's actually safe via some other argument, but people have been convincing themselves that their code is memory safe for decades and they're often wrong. More insidiously, relying on anything in Rust that uses "unsafe" makes it seem like the compiler is proving your own code is safe, but that is no longer true. With that said, I don't really disagree with what I think your main point is. But seeing unsafe code in Rust is similar to seeing unsafePerformIO in Haskell libraries. Both of these are much more common than the languages' respective evangelists would have you believe, and at some point it actually does start to call into question whether the languages are successful at their basic design goals. (Spoiler: I believe that they are successful more than they are not, and even in the face of the proliferation of "unsafe" code in both languages, they're still worth using.)
    - zozbot234 6y ago
      The compiler has very limited "proof" capabilities even in principle, especially wrt. unsafe{} code. From a principled POV it would be nice to be able to provide a formal, compiler-checked proof that some block of code that has to rely on "unsafe" operations doesn't actually violate the language safety guarantees and can be wrapped safely. But this will have to depend on a formal model of "unsafe" itself which is still lacking. And it wouldn't even help for things like FFI, which involves calls into outside code for which the semantics are not formally known.
    - staticassertion 6y ago
      > The whole selling point of Rust is that it's supposed to let you write provably safe code. I disagree. A significant purpose of rust is to encapsulate unsafe code, and provide safe abstractions. Lots of unsafe code is safe - most of it, even, I'd bet.
      - nilkn 6y ago
        > Lots of unsafe code is safe I mean this with the greatest possible respect, but you replied by simply restating verbatim the quote that I originally responded to, so I'll just point you to my previous post.
bjourne 6y ago
Rust doesn't check for numerical over and underflows unless you run in debug mode which almost no one does because it is about two times slower than release mode. I.e. Rust doesn't live up to the safety standards many programmers coming from dynamic languages are used to where over and underflows are checked. Many people in the Rust community appear to be unaware of this. Which is actually a big deal. Many of the bugs with the most catastrophic consequences are caused by over and underflows. Consider for example a gas pedal indicator kept as an unsigned that underflows causing the indicator to reach its maximum value. If safety was my primary concern, I wouldn't choose C++ but I wouldn't choose Rust either.
- smitop 6y ago
  You can pass "-C overflow-checks=on" to rustc to generate an optimized build with over/underflow checks enabled, even in a release build. Also, note that over/underflow behavior is defined to always be two's compliment wrapping when overflow checks are disabled.
- staticassertion 6y ago
  > Rust doesn't check for numerical over and underflows unless you run in debug mode which almost no one does because it is about two times slower than release mode. Totally, I wish Rust could express over/underflows better! > Rust doesn't live up to the safety standards many programmers coming from dynamic languages are used to where over and underflows are checked. > Rust doesn't live up to the safety standards many programmers coming from dynamic languages are used to where over and underflows are checked. Yeah, that's possible. Thought it won't lead to unsafety, it is definitely a gotcha. > Many people in the Rust community appear to be unaware of this. Which is actually a big deal. Maybe, not sure. > If safety was my primary concern, I wouldn't choose C++ but I wouldn't choose Rust either. Really depends on the goals and constraints, of course. I'd be really concerned about using rust where an integer overflow could kill someone. I'd be really happy to use rust where a program crashing is totally acceptable, but exploitability isn't.
- acje 6y ago
  Rust is memory safe, not infallible. Catching more runtime errors is a something rust can improve on. Erlang being one example of a strategy.

zozbot234 6y ago

> "All bets are off" is an insane way to characterize this. Well, it depends. If the unsafe{} code is also unsound, then "all bets are off" is quite correct because you can't assume memory safety or lack of UB, even in your own code. In practice, you can use cargo-geiger to warn about crates that internally rely on unsafe code, and cargo-audit will warn about known security issues (including but not limited to unsoundness and memory-unsafety).

staticassertion 6y ago
> then "all bets are off" is quite correct because you can't assume memory safety or lack of UB, even in your own code. The problem with "All bets are off" is it's not meaningful. What does that mean? It's so vague. Lots of unsafe code is safe. Lots of UB is not exploitable. I can link to a vulnerable crate and not be vulnerable. Can there be an exploitable bug in rust code? Yeah, sure. But saying "all bets are off" gives the impression of "why even bother if you link to unsafe code", which is absurd. Yeah, we should strive for more safe code, audit unsafe code, be very cautious about using it, but "all bets are off" come on.
- saagarjha 6y ago
  Well, there's two interpretations of "all bets are off". One is the runtime one, which is if you have a bug in unsafe code, then it is possible that all the other code in your program is safe but you're still totally out of luck because it can invalidate every guarantee. However, from an auditing perspective, the only code you need to look at for memory safety issues is that particular snippet, so you're in a much better position from that perspective.
- nilkn 6y ago
  > Lots of unsafe code is safe. This seems like a weird statement to make to me when defending Rust simultaneously. The whole selling point of Rust is that it's supposed to let you write provably safe code. When "unsafe" is used, what you're writing can no longer be proven as safe by the compiler. Maybe you've convinced yourself it's actually safe via some other argument, but people have been convincing themselves that their code is memory safe for decades and they're often wrong. More insidiously, relying on anything in Rust that uses "unsafe" makes it seem like the compiler is proving your own code is safe, but that is no longer true. With that said, I don't really disagree with what I think your main point is. But seeing unsafe code in Rust is similar to seeing unsafePerformIO in Haskell libraries. Both of these are much more common than the languages' respective evangelists would have you believe, and at some point it actually does start to call into question whether the languages are successful at their basic design goals. (Spoiler: I believe that they are successful more than they are not, and even in the face of the proliferation of "unsafe" code in both languages, they're still worth using.)
  - zozbot234 6y ago
    The compiler has very limited "proof" capabilities even in principle, especially wrt. unsafe{} code. From a principled POV it would be nice to be able to provide a formal, compiler-checked proof that some block of code that has to rely on "unsafe" operations doesn't actually violate the language safety guarantees and can be wrapped safely. But this will have to depend on a formal model of "unsafe" itself which is still lacking. And it wouldn't even help for things like FFI, which involves calls into outside code for which the semantics are not formally known.
  - staticassertion 6y ago
    > The whole selling point of Rust is that it's supposed to let you write provably safe code. I disagree. A significant purpose of rust is to encapsulate unsafe code, and provide safe abstractions. Lots of unsafe code is safe - most of it, even, I'd bet.
    - nilkn 6y ago
      > Lots of unsafe code is safe I mean this with the greatest possible respect, but you replied by simply restating verbatim the quote that I originally responded to, so I'll just point you to my previous post.

bjourne 6y ago

Rust doesn't check for numerical over and underflows unless you run in debug mode which almost no one does because it is about two times slower than release mode. I.e. Rust doesn't live up to the safety standards many programmers coming from dynamic languages are used to where over and underflows are checked. Many people in the Rust community appear to be unaware of this. Which is actually a big deal. Many of the bugs with the most catastrophic consequences are caused by over and underflows. Consider for example a gas pedal indicator kept as an unsigned that underflows causing the indicator to reach its maximum value. If safety was my primary concern, I wouldn't choose C++ but I wouldn't choose Rust either.

smitop 6y ago
You can pass "-C overflow-checks=on" to rustc to generate an optimized build with over/underflow checks enabled, even in a release build. Also, note that over/underflow behavior is defined to always be two's compliment wrapping when overflow checks are disabled.
staticassertion 6y ago
> Rust doesn't check for numerical over and underflows unless you run in debug mode which almost no one does because it is about two times slower than release mode. Totally, I wish Rust could express over/underflows better! > Rust doesn't live up to the safety standards many programmers coming from dynamic languages are used to where over and underflows are checked. > Rust doesn't live up to the safety standards many programmers coming from dynamic languages are used to where over and underflows are checked. Yeah, that's possible. Thought it won't lead to unsafety, it is definitely a gotcha. > Many people in the Rust community appear to be unaware of this. Which is actually a big deal. Maybe, not sure. > If safety was my primary concern, I wouldn't choose C++ but I wouldn't choose Rust either. Really depends on the goals and constraints, of course. I'd be really concerned about using rust where an integer overflow could kill someone. I'd be really happy to use rust where a program crashing is totally acceptable, but exploitability isn't.
acje 6y ago
Rust is memory safe, not infallible. Catching more runtime errors is a something rust can improve on. Erlang being one example of a strategy.