4 ms·

What safety feature does rust lack exactly? I know C++ has some more expressive features (like templates on values), but safety? C++ is as unsafe as it gets…

by c-cube 8y ago

The_rationalist 8y ago
On the langage on itself rust lack many expressives features (but "slowly" catch up) that modern c++ has. As for memory safety, I'm not aware of safety features on the Langage on itself but the rust tooling is like third world in comparison. First of all rust has a very incomplete sanitizers support. Ubsan, Msan etc https://github.com/rust-lang/rust/issues/39699 https://github.com/rust-lang/rust/issues/39699 Secondly there is an order of magnitude more static analysis tools that support cpp than rust (but Facebook (a leader in static analysis) is developing a promising one for rust. As for Fuzzers I'm not aware if they're Langage agnostic. Finally there are less (if none?) program provers for rust code.
- wwright 8y ago
  Sanitizers and fuzzers are a valid complaint, but static analysis is much less of a problem for Rust vs C++. Most of the issues C++ analyzers detect are prevented by Rust’s design itself, and Rust has an official analyzer in Clippy. Provers are also a fair complaint, though it’s going to be comparatively super rare that that is an issue in practice :p
- the_why_of_y 8y ago
  There may be more static analysis tools available for C++, but the quality of the static analysis built right into Rust's type system blows all of them out of the water; no tool for C++ that I've used (Coverity, Infer, PVS-Studio, ...) can reliably prevent use-after-free or data races. Due to the type system, safe Rust code has much less need for sanitizers (leaks and lock order checks are useful) or fuzzers (they'll only find infinite loops); granted, you do have a point in that sanitizers are very useful for unsafe Rust code. There's AFL for Rust: https://github.com/rust-fuzz/afl.rs https://github.com/rust-fuzz/afl.rs [Edit:] With regard to theorem provers, my understanding is that you typically work in some sort of functional language and the correct C/C++ code is generated as a final step at the end (program extraction); certainly Coq and the HOL family work that way. There's already Rust program extraction for Coq, although I wouldn't be surprised if it's not as mature as C yet: https://github.com/pirapira/coq2rust https://github.com/pirapira/coq2rust In other areas, Rust already has an advantage; compare Cargo with the Babylonian chaos of C++ build sytems, where the question isn't even which one you want to use, but how many different ones are imposed on you by external constraints and how to integrate them without going crazy.
hedora 8y ago
C++ semantics are no less safe than any other language with an “unsafe” mode. The difference is that C++ makes it convenient to write unsafe code, but that it also makes it possible to write safe systems code at a much higher level of abstraction than any other language I’ve heard of (templates are Turing complete, and modern tooling makes them reasonable to work with). So, the question is, what does Rust make C++ developers give up that can’t be achieved via C++ style guidelines? Also, 10 years from now, when the state of the art of systems programming advances, we’ll be able to backport the ideas C++ (just like we do today). Does Rust have a track record of supporting that?
- vvanders 8y ago
  C++ makes it really easy to corrupt the heap or stack which depending on tooling can take days or weeks to track down. I don't mind trading a bit of flexibility with and optional escape hatch (unsafe). I'm really skeptical of backporting Rust's wins to C++. The concept of mutability cuts across the language and I don't see how you do it without bifrucating an already complicated language.
  - UncleEntity 8y ago
    > The concept of mutability cuts across the language and I don't see how you do it without bifrucating an already complicated language. How hard would it really be for someone to write a static analyzer for C++ that ensures there is only one non-const reference/pointer to an object active at any given time? Throw in an object lifetime tracker for allocs and you'd have pretty safe C++ without having to rewrite a billion line of code.
    - deleted 8y ago
      [deleted]
    - pjmlp 8y ago
      Microsoft and Google are having a go at it.
- c-cube 8y ago
pjmlp 8y ago
Contracts, static analysis is still in infancy (clippy vs PVS-Studio). While C's copy-paste compatibility is C++ security story Achilles heel, there is still quite a lot that can be used for writing safer code.
- littlestymaar 8y ago
  As far as you only use safe Rust, static analysis is in a way better shape than C++, just because C++ has nothing as powerful as the borrow checker.
  - pjmlp 8y ago
    Google and Microsoft are working on adding one to clang and Visual C++ static analysers. https://herbsutter.com/2018/09/20/lifetime-profile-v1-0-posted/ https://herbsutter.com/2018/09/20/lifetime-profile-v1-0-post...
    - littlestymaar 8y ago
      And it will probably be incomplete because C++ hasn't be designed with it in mind (How do you avoid shared mutability when everything is mutable by default ?). Yet, this is good to see C++ trying to catch-up. (And if it's catching up, it means Rust is ahead in terms of static analysis ;)
jandrewrogers 8y ago
Compile-time code/type generation and verification, which leverages advanced template functionality and constexpr extensively. For applications like database engines with dense, complex data structure interactions, this facility allows you to make fairly deep guarantees about correctness at compile-time that would otherwise require mountains of runtime assertions that as a practical matter programmers won't write with sufficient coverage and may not be tripped in testing in any case. If you make code/design changes, it won't compile if you've introduced one of many common bug types that are otherwise hard to detect when writing code. In my experience, these kinds of bugs are more common than memory safety bugs (which in my experience are a non-issue for modern C++). This is fairly magical when you use it but it requires a different coding style than some systems programmers are used to. Instead of writing code, you end up writing a lot of meta-code that generates and verifies what actually gets compiled. Recent versions of C++ have invested a lot in making these facilities expressive and reasonable to use in complex software. In my experience this has substantially reduced the code defect rate and simplified testing. Once you've written a system this way, it is very hard to go back. Not having these facilities would be a huge step backward for writing practical high-assurance/high-reliability code. AFAICT, Rust is still quite primitive in this regard.
- 0815test 8y ago
  > Compile-time code/type generation and verification Rust does have a procedural macro system which can be used to do these things. Surely actual procedural macros are better than hacking the template system to generate custom code, which is the typical approach in C++.
  - jandrewrogers 8y ago
    This is not remotely the same. You are seriously underestimating the capabilities of C++17 in this regard.
    - JoachimSchipper 8y ago
      Do you happen to have a link to a page explaining these techniques? I code in C and dabble in Rust, but this sounds interesting. (Sorry, I know this is a few days old by now...)

What safety feature does rust lack exactly? I know C++ has some more expressive features (like templates on values), but safety? C++ is as unsafe as it gets…

by c-cube 8y ago

What safety feature does rust lack exactly? I know C++ has some more expressive features (like templates on values), but safety? C++ is as unsafe as it gets…

The_rationalist 8y ago

On the langage on itself rust lack many expressives features (but "slowly" catch up) that modern c++ has. As for memory safety, I'm not aware of safety features on the Langage on itself but the rust tooling is like third world in comparison. First of all rust has a very incomplete sanitizers support. Ubsan, Msan etc https://github.com/rust-lang/rust/issues/39699 https://github.com/rust-lang/rust/issues/39699 Secondly there is an order of magnitude more static analysis tools that support cpp than rust (but Facebook (a leader in static analysis) is developing a promising one for rust. As for Fuzzers I'm not aware if they're Langage agnostic. Finally there are less (if none?) program provers for rust code.

wwright 8y ago
Sanitizers and fuzzers are a valid complaint, but static analysis is much less of a problem for Rust vs C++. Most of the issues C++ analyzers detect are prevented by Rust’s design itself, and Rust has an official analyzer in Clippy. Provers are also a fair complaint, though it’s going to be comparatively super rare that that is an issue in practice :p
the_why_of_y 8y ago
There may be more static analysis tools available for C++, but the quality of the static analysis built right into Rust's type system blows all of them out of the water; no tool for C++ that I've used (Coverity, Infer, PVS-Studio, ...) can reliably prevent use-after-free or data races. Due to the type system, safe Rust code has much less need for sanitizers (leaks and lock order checks are useful) or fuzzers (they'll only find infinite loops); granted, you do have a point in that sanitizers are very useful for unsafe Rust code. There's AFL for Rust: https://github.com/rust-fuzz/afl.rs https://github.com/rust-fuzz/afl.rs [Edit:] With regard to theorem provers, my understanding is that you typically work in some sort of functional language and the correct C/C++ code is generated as a final step at the end (program extraction); certainly Coq and the HOL family work that way. There's already Rust program extraction for Coq, although I wouldn't be surprised if it's not as mature as C yet: https://github.com/pirapira/coq2rust https://github.com/pirapira/coq2rust In other areas, Rust already has an advantage; compare Cargo with the Babylonian chaos of C++ build sytems, where the question isn't even which one you want to use, but how many different ones are imposed on you by external constraints and how to integrate them without going crazy.

hedora 8y ago

C++ semantics are no less safe than any other language with an “unsafe” mode. The difference is that C++ makes it convenient to write unsafe code, but that it also makes it possible to write safe systems code at a much higher level of abstraction than any other language I’ve heard of (templates are Turing complete, and modern tooling makes them reasonable to work with). So, the question is, what does Rust make C++ developers give up that can’t be achieved via C++ style guidelines? Also, 10 years from now, when the state of the art of systems programming advances, we’ll be able to backport the ideas C++ (just like we do today). Does Rust have a track record of supporting that?

vvanders 8y ago
C++ makes it really easy to corrupt the heap or stack which depending on tooling can take days or weeks to track down. I don't mind trading a bit of flexibility with and optional escape hatch (unsafe). I'm really skeptical of backporting Rust's wins to C++. The concept of mutability cuts across the language and I don't see how you do it without bifrucating an already complicated language.
- UncleEntity 8y ago
  > The concept of mutability cuts across the language and I don't see how you do it without bifrucating an already complicated language. How hard would it really be for someone to write a static analyzer for C++ that ensures there is only one non-const reference/pointer to an object active at any given time? Throw in an object lifetime tracker for allocs and you'd have pretty safe C++ without having to rewrite a billion line of code.
  - deleted 8y ago
    [deleted]
  - pjmlp 8y ago
    Microsoft and Google are having a go at it.
c-cube 8y ago

pjmlp 8y ago

Contracts, static analysis is still in infancy (clippy vs PVS-Studio). While C's copy-paste compatibility is C++ security story Achilles heel, there is still quite a lot that can be used for writing safer code.

littlestymaar 8y ago
As far as you only use safe Rust, static analysis is in a way better shape than C++, just because C++ has nothing as powerful as the borrow checker.
- pjmlp 8y ago
  Google and Microsoft are working on adding one to clang and Visual C++ static analysers. https://herbsutter.com/2018/09/20/lifetime-profile-v1-0-posted/ https://herbsutter.com/2018/09/20/lifetime-profile-v1-0-post...
  - littlestymaar 8y ago
    And it will probably be incomplete because C++ hasn't be designed with it in mind (How do you avoid shared mutability when everything is mutable by default ?). Yet, this is good to see C++ trying to catch-up. (And if it's catching up, it means Rust is ahead in terms of static analysis ;)

jandrewrogers 8y ago

Compile-time code/type generation and verification, which leverages advanced template functionality and constexpr extensively. For applications like database engines with dense, complex data structure interactions, this facility allows you to make fairly deep guarantees about correctness at compile-time that would otherwise require mountains of runtime assertions that as a practical matter programmers won't write with sufficient coverage and may not be tripped in testing in any case. If you make code/design changes, it won't compile if you've introduced one of many common bug types that are otherwise hard to detect when writing code. In my experience, these kinds of bugs are more common than memory safety bugs (which in my experience are a non-issue for modern C++). This is fairly magical when you use it but it requires a different coding style than some systems programmers are used to. Instead of writing code, you end up writing a lot of meta-code that generates and verifies what actually gets compiled. Recent versions of C++ have invested a lot in making these facilities expressive and reasonable to use in complex software. In my experience this has substantially reduced the code defect rate and simplified testing. Once you've written a system this way, it is very hard to go back. Not having these facilities would be a huge step backward for writing practical high-assurance/high-reliability code. AFAICT, Rust is still quite primitive in this regard.

0815test 8y ago
> Compile-time code/type generation and verification Rust does have a procedural macro system which can be used to do these things. Surely actual procedural macros are better than hacking the template system to generate custom code, which is the typical approach in C++.
- jandrewrogers 8y ago
  This is not remotely the same. You are seriously underestimating the capabilities of C++17 in this regard.
  - JoachimSchipper 8y ago
    Do you happen to have a link to a page explaining these techniques? I code in C and dabble in Rust, but this sounds interesting. (Sorry, I know this is a few days old by now...)