5 ms·

Rust also relies on best practices. It is best practice not to use `unsafe` blocks unless absolutely needed. That does not mean Rust is an unsafe language.

Cyph0n 5y ago
1. The corollary is that code that does not contain unsafe code is guaranteed to not contain memory safety bugs, assuming that you trust and/or have audited unsafe usage in your dependencies. 2. unsafe blocks are explicit and therefore visible during code review. Memory safety violations in C++ are not always visible, simply because they are implicit. 3. Thanks to (2), unsafe usage in a codebase can be easily quantified and, if needed, audited.
- mgaunard 5y ago
  Violations to the C++ best practices that enforce memory safety are definitely visible during code reviews. The harder problem is convincing people that raising their quality standards is a necessary requirement for them to contribute to the code.
  - Cyph0n 5y ago
    Firstly, the difference I was trying to emphasize is "guaranteed to be visible due to the unsafe keyword" vs. "potentially not visible". Secondly, quality standards rely on the human element, which we know is fallible and never 100% reliable. Compiler-enforced memory safety checks are (in theory) infallible[1]. [1]: Infallible when all of your dependencies are also verifiably memory safe. In reality, this is not the case, but I believe that Rust can reliably get much closer to 100% than usual.
- nineteen999 5y ago
  > 1. The corollary is that code that does not contain unsafe code is guaranteed to not contain memory safety bugs, assuming that you trust and/or have audited unsafe usage in your dependencies. Doesn't this assume that there are no bugs in the Rust compiler (for "safe" code)? Isn't that still somewhat of a big assumption at this point? I get that is indeed a very core goal of Rust, but has this been proven for any/all released versions of the Rust compilers?
  - Cyph0n 5y ago
    It ultimately depends on how you define your TCB (trusted computing base). I am not aware of any formally verified compilers for any language, but assuming one exists, wouldn't you also require said compiler to run on a formally verified OS? Also, how do you tackle the infamous "Reflections on Trusting Trust" compiler attack? It's turtles all the way down :) Long story short, for the vast majority of use-cases, developers can assume that the compiler and stdlib are trusted. This is also how Rust defines "safety", which leaves you to focus on your code and its dependencies.
    - nineteen999 5y ago
      Not talking about situations where the compiler or the OS are compromised - of course all bets are off in those situations. But "guaranteed" that there can be no security holes in code marked "safe" due to an inadvertent compiler bug? I would be very surprised if that is actually the case. Less likely than C/C++? Yes of course. Guaranteed? Probably not.
      - Cyph0n 5y ago
        An inadvertent bug in the compiler can be modeled as a compromise. So, as before, it depends on how you define “safe” in your model. In the case of Rust, the compiler is safe and is considered to be within the safety boundary. Will the Rust compiler have bugs in practice? Of course. Do you - as a developer - have a different safety model than the Rust language (i.e., one that does not include the compiler)? If the answer is no, you can “ignore” compiler bugs from a safety perspective.

Cyph0n 5y ago

1. The corollary is that code that does not contain unsafe code is guaranteed to not contain memory safety bugs, assuming that you trust and/or have audited unsafe usage in your dependencies. 2. unsafe blocks are explicit and therefore visible during code review. Memory safety violations in C++ are not always visible, simply because they are implicit. 3. Thanks to (2), unsafe usage in a codebase can be easily quantified and, if needed, audited.

mgaunard 5y ago
Violations to the C++ best practices that enforce memory safety are definitely visible during code reviews. The harder problem is convincing people that raising their quality standards is a necessary requirement for them to contribute to the code.
- Cyph0n 5y ago
  Firstly, the difference I was trying to emphasize is "guaranteed to be visible due to the unsafe keyword" vs. "potentially not visible". Secondly, quality standards rely on the human element, which we know is fallible and never 100% reliable. Compiler-enforced memory safety checks are (in theory) infallible[1]. [1]: Infallible when all of your dependencies are also verifiably memory safe. In reality, this is not the case, but I believe that Rust can reliably get much closer to 100% than usual.
nineteen999 5y ago
> 1. The corollary is that code that does not contain unsafe code is guaranteed to not contain memory safety bugs, assuming that you trust and/or have audited unsafe usage in your dependencies. Doesn't this assume that there are no bugs in the Rust compiler (for "safe" code)? Isn't that still somewhat of a big assumption at this point? I get that is indeed a very core goal of Rust, but has this been proven for any/all released versions of the Rust compilers?
- Cyph0n 5y ago
  It ultimately depends on how you define your TCB (trusted computing base). I am not aware of any formally verified compilers for any language, but assuming one exists, wouldn't you also require said compiler to run on a formally verified OS? Also, how do you tackle the infamous "Reflections on Trusting Trust" compiler attack? It's turtles all the way down :) Long story short, for the vast majority of use-cases, developers can assume that the compiler and stdlib are trusted. This is also how Rust defines "safety", which leaves you to focus on your code and its dependencies.
  - nineteen999 5y ago
    Not talking about situations where the compiler or the OS are compromised - of course all bets are off in those situations. But "guaranteed" that there can be no security holes in code marked "safe" due to an inadvertent compiler bug? I would be very surprised if that is actually the case. Less likely than C/C++? Yes of course. Guaranteed? Probably not.
    - Cyph0n 5y ago
      An inadvertent bug in the compiler can be modeled as a compromise. So, as before, it depends on how you define “safe” in your model. In the case of Rust, the compiler is safe and is considered to be within the safety boundary. Will the Rust compiler have bugs in practice? Of course. Do you - as a developer - have a different safety model than the Rust language (i.e., one that does not include the compiler)? If the answer is no, you can “ignore” compiler bugs from a safety perspective.