7 ms·

I'm really sorry but memory safety reliant on best practices is not memory safety.

by varjag 5y ago

mumblemumble 5y ago
It's long been done fairly successfully in business domains like aerospace and firmware development. Where I'm less convinced that it's an option with a high likelihood of success is in open source. It's one thing when you've got a $250,000 salary riding on you ability to scrupulously follow best practices. But results may vary when the work is being done on an amateur basis.
- varjag 5y ago
  I'm doing embedded development day and night, so am aware how prolific C is. That however does not make it memory safe. 'Best practices' really means using humans as compiler preprocessors and hedges on humans being infallible.
- xxpor 5y ago
  >you've got a $250,000 salary riding on you ability to scrupulously follow best practices Sounds like a great way to have a toxic workplace that either yells at people for bugs, or never gets anything done because people are paranoid about committing bugs (or both!). Meanwhile, with a different language you get the compiler yelling at you instead. Automated enforcement uber alles. I don't think open source vs commercial dev really matters that much.
- adwn 5y ago
  > But results may vary when the work is being done on an amateur basis. Much, if not most, of Linux kernel development is done by employees of various companies, who are being paid for their work. Typically, that's in the form of device drivers, which also happens to be where I've seen the shoddiest, buggiest code in the kernel [1]. [1] Think "driver A abusing the 'private' pointer of driver B for its own purposes" kind of buggy.
- Too 5y ago
  If by successful you mean where changing one line of code takes 2 weeks of change request, 2 weeks of requirement analysis, 2 weeks of system specification translation, 2 weeks of test specification, 2 weeks of test case implementation, 1 day of implementation and finally 2 weeks of code review, and so on. Then yes, you are completely right. In aerospace you probably want all this anyway, but for others, where 99.99% is enough, there needs to be a cheaper and more efficient way.
gravypod 5y ago
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?

I'm really sorry but memory safety reliant on best practices is not memory safety.

by varjag 5y ago

I'm really sorry but memory safety reliant on best practices is not memory safety.

It's long been done fairly successfully in business domains like aerospace and firmware development. Where I'm less convinced that it's an option with a high likelihood of success is in open source. It's one thing when you've got a $250,000 salary riding on you ability to scrupulously follow best practices. But results may vary when the work is being done on an amateur basis.

varjag 5y ago
I'm doing embedded development day and night, so am aware how prolific C is. That however does not make it memory safe. 'Best practices' really means using humans as compiler preprocessors and hedges on humans being infallible.
xxpor 5y ago
>you've got a $250,000 salary riding on you ability to scrupulously follow best practices Sounds like a great way to have a toxic workplace that either yells at people for bugs, or never gets anything done because people are paranoid about committing bugs (or both!). Meanwhile, with a different language you get the compiler yelling at you instead. Automated enforcement uber alles. I don't think open source vs commercial dev really matters that much.
adwn 5y ago
> But results may vary when the work is being done on an amateur basis. Much, if not most, of Linux kernel development is done by employees of various companies, who are being paid for their work. Typically, that's in the form of device drivers, which also happens to be where I've seen the shoddiest, buggiest code in the kernel [1]. [1] Think "driver A abusing the 'private' pointer of driver B for its own purposes" kind of buggy.
Too 5y ago
If by successful you mean where changing one line of code takes 2 weeks of change request, 2 weeks of requirement analysis, 2 weeks of system specification translation, 2 weeks of test specification, 2 weeks of test case implementation, 1 day of implementation and finally 2 weeks of code review, and so on. Then yes, you are completely right. In aerospace you probably want all this anyway, but for others, where 99.99% is enough, there needs to be a cheaper and more efficient way.

gravypod 5y ago

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?