4 ms·

> I gave you a trove of real world examples of serious security issues in widely used software developed by competent teams. Quite a few of these would have not

> I gave you a trove of real world examples of serious security issues in widely used software developed by competent teams. Quite a few of these would have not existed in a language with the kind of guarantees that Rust provides. How is this disingenuous? Genuine question : do we know that those bugs would have been avoided using rust? Maybe some of those part would have had to be done unsafe mode for some reasons. > Take a look at the OpenBSD bug - any user can kernel panic the whole host, a massive security issue. Are the OpenBSD maintainers, in your opinion, "idiotic"? Or that Xen bug - privilege escalation. Are the Xen developers, in your opinion "imbeciles"? What about all the OpenSSL / OpenSSH ones? Perhaps they're "bad at C"? When was this code written ? you are comparing old C code with (non existant/hypothetic) rust code. How do you know the rust wouldn't slower ? > The truth is that as code gets more complex, writing safe code becomes harder. The above is evidence that even smart and experienced people regularly cause colossal bugs that have real life implications. That we completely agree on, but we learn quite a bit on how to write better code. Some of that knowledge got embedded in compilers/compilers warnings and tooling, some retrofitted in the languages themselves , some through libraries design and coding guideline etc... My main problem with your argument is that you saying that a code written in rust today would be safer than a code written in C/C++ decades ago...That's probably true. I think a much more interesting question is how much safer a code written in rust today would be vs a C/C++ code written today , reflecting our current understanding and knowledge on how to build safe system.

pcwalton 10y ago
> I think a much more interesting question is how much safer a code written in rust today would be vs a C/C++ code written today , reflecting our current understanding and knowledge on how to build safe system. A lot safer, judging by browser exploits.
- soulbadguy 10y ago
  > reflecting our current understanding and knowledge on how to build safe system...
  - pcwalton 10y ago
    Browser engines are more indicative of the current "understanding and knowledge of how to build safe systems" than nearly any C++ codebase in existence. Part of the current "understanding and knowledge of how to build safe systems" is to use a memory-safe language.
  - mmstick 10y ago
    Despite all the flashy tools that proponents of C and C++ claim that makes C++ as safe as Rust, it's not doing any good at stopping the exponentially-increasing amount of vulnerabilities and crashes that are being reported over the last few years.
    - Rusky 10y ago
      You have no data at all to back this up. The vulnerabilities you speak of are, far more often than not, written in old-style C and C++. That doesn't make Rust a bad idea, but it does mean your claim is completely unsubstantiated. Advocating for Rust by lying is not going to help anyone.
      - deleted 10y ago
        [deleted]
      - mmstick 10y ago
        This is the same line of logic and statements repeated by C and C++ programmers that shortly thereafter get showed up with a list of CVEs in their 'modern C/C++' projects. Remember the recent Curl developer PR disaster?
        flukus 10y ago
        I think it's too early to tell if rust will prove any better in the real world, which includes things like devs using unsafe sections to cope with time pressures.
        10y ago
jostmon 10y ago
You seem to be presupposing that all, or much of the C/C++ written today will follow best practices and be written by "expert" programers. A portion will, perhaps even a substantial portion, but I'd be willing to wager a far larger portion of the Rust written today will follow best practices and doesn't have to be written by expert programers. This is because the safety in Rust isn't optional, like it is with C/C++ best practices/new features.
- soulbadguy 10y ago
  > You seem to be presupposing that all, or much of the C/C++ written today will follow best practices and be written by "expert" programmers No, the argument i am trying to make is that if someone wants safe and reliable code, it's possible to buy that in C/C++ at cheaper price than to migrate to whole new language and platform. > I'd be willing to wager a far larger portion of the Rust written today will follow best practices Yes, as you mentioned that's by design. But i don't that the metric we should be looking at : in the group of people/team/compagny who actually care about safety and performance ( and let's be honest that group is the biggest one), what proportion will be using C++ vs rust.
scottlamb 10y ago
> Genuine question : do we know that those bugs would have been avoided using rust? Maybe some of those part would have had to be done unsafe mode for some reasons. AFAIK no one's done a comprehensive survey, and it'd be hard to know for certain what someone would choose to use unsafe for until/unless they actually rewrite the code in question into Rust. But if you look at code that is written in Rust today, I think you'll find less than 1% of the code is unsafe. [1] I think it's used for * FFI / interfacing with C (common now, but less so the more you rewrite into Rust), * low-level code (such as synchronization primitives and data structures), and * a few bits of performance-sensitive code. My gut feeling is that many of these bugs are in safe code, the "boring" 99%. The bugs would either be prevented by the compiler or turned into a panic at runtime instead of undefined behavior. When people use unsafe, I'd like to think having to explicitly flag it as such would make authors and reviewers more careful. But certainly there's no 100% guarantee; I've seen broken unsafe Rust code in the wild already. As a small example, sqlite3::core::ResultRow::column_slice [2] is unsound; a following call to another column_* method would invalidate the returned pointer, [3] but as they all take a &self nothing prevents you from using the pointer after it's no longer valid. column_slice should take a &mut self instead. I haven't reported the bug because this buggy crate has been marked obsolete in favor of rusqlite. [1] For a project of mine, it's found on 0.3% of non-comment-non-blank lines (23 unsafes / 7,390 lines). 13 of those were for FFI; the remaining 10 were due to my unfortunate obsession with optimizing for CPU. If anyone's done an accounting of more/larger projects, I'd be curious to hear it. [2] http://www.madmode.com/rust-sqlite3/sqlite3/core/struct.ResultRow.html http://www.madmode.com/rust-sqlite3/sqlite3/core/struct.Resu... [3] https://www.sqlite.org/capi3ref.html#sqlite3_column_blob https://www.sqlite.org/capi3ref.html#sqlite3_column_blob

pcwalton 10y ago

> I think a much more interesting question is how much safer a code written in rust today would be vs a C/C++ code written today , reflecting our current understanding and knowledge on how to build safe system. A lot safer, judging by browser exploits.

soulbadguy 10y ago
> reflecting our current understanding and knowledge on how to build safe system...
- pcwalton 10y ago
  Browser engines are more indicative of the current "understanding and knowledge of how to build safe systems" than nearly any C++ codebase in existence. Part of the current "understanding and knowledge of how to build safe systems" is to use a memory-safe language.
- mmstick 10y ago
  Despite all the flashy tools that proponents of C and C++ claim that makes C++ as safe as Rust, it's not doing any good at stopping the exponentially-increasing amount of vulnerabilities and crashes that are being reported over the last few years.
  - Rusky 10y ago
    You have no data at all to back this up. The vulnerabilities you speak of are, far more often than not, written in old-style C and C++. That doesn't make Rust a bad idea, but it does mean your claim is completely unsubstantiated. Advocating for Rust by lying is not going to help anyone.
    - deleted 10y ago
      [deleted]
    - mmstick 10y ago
      This is the same line of logic and statements repeated by C and C++ programmers that shortly thereafter get showed up with a list of CVEs in their 'modern C/C++' projects. Remember the recent Curl developer PR disaster?
      - flukus 10y ago
        I think it's too early to tell if rust will prove any better in the real world, which includes things like devs using unsafe sections to cope with time pressures.
        10y ago

jostmon 10y ago

You seem to be presupposing that all, or much of the C/C++ written today will follow best practices and be written by "expert" programers. A portion will, perhaps even a substantial portion, but I'd be willing to wager a far larger portion of the Rust written today will follow best practices and doesn't have to be written by expert programers. This is because the safety in Rust isn't optional, like it is with C/C++ best practices/new features.

soulbadguy 10y ago
> You seem to be presupposing that all, or much of the C/C++ written today will follow best practices and be written by "expert" programmers No, the argument i am trying to make is that if someone wants safe and reliable code, it's possible to buy that in C/C++ at cheaper price than to migrate to whole new language and platform. > I'd be willing to wager a far larger portion of the Rust written today will follow best practices Yes, as you mentioned that's by design. But i don't that the metric we should be looking at : in the group of people/team/compagny who actually care about safety and performance ( and let's be honest that group is the biggest one), what proportion will be using C++ vs rust.

scottlamb 10y ago

> Genuine question : do we know that those bugs would have been avoided using rust? Maybe some of those part would have had to be done unsafe mode for some reasons. AFAIK no one's done a comprehensive survey, and it'd be hard to know for certain what someone would choose to use unsafe for until/unless they actually rewrite the code in question into Rust. But if you look at code that is written in Rust today, I think you'll find less than 1% of the code is unsafe. [1] I think it's used for * FFI / interfacing with C (common now, but less so the more you rewrite into Rust), * low-level code (such as synchronization primitives and data structures), and * a few bits of performance-sensitive code. My gut feeling is that many of these bugs are in safe code, the "boring" 99%. The bugs would either be prevented by the compiler or turned into a panic at runtime instead of undefined behavior. When people use unsafe, I'd like to think having to explicitly flag it as such would make authors and reviewers more careful. But certainly there's no 100% guarantee; I've seen broken unsafe Rust code in the wild already. As a small example, sqlite3::core::ResultRow::column_slice [2] is unsound; a following call to another column_* method would invalidate the returned pointer, [3] but as they all take a &self nothing prevents you from using the pointer after it's no longer valid. column_slice should take a &mut self instead. I haven't reported the bug because this buggy crate has been marked obsolete in favor of rusqlite. [1] For a project of mine, it's found on 0.3% of non-comment-non-blank lines (23 unsafes / 7,390 lines). 13 of those were for FFI; the remaining 10 were due to my unfortunate obsession with optimizing for CPU. If anyone's done an accounting of more/larger projects, I'd be curious to hear it. [2] http://www.madmode.com/rust-sqlite3/sqlite3/core/struct.ResultRow.html http://www.madmode.com/rust-sqlite3/sqlite3/core/struct.Resu... [3] https://www.sqlite.org/capi3ref.html#sqlite3_column_blob https://www.sqlite.org/capi3ref.html#sqlite3_column_blob