6 ms·

> and the rate of change is low (or zero) This jives with a point that the Google Security Blog made last year: "The [memory safety] problem is overwhelmingly

• miohtama 1y ago
  You can find historical SQLite CVEs here https://www.sqlite.org/cves.html https://www.sqlite.org/cves.html Note that although code matures the chances of C Human error bugs will never go to zero. We have some bad incidents like Heartbleed to show this.
  • ziotom78 1y ago
    Right, but I believe nobody can claim that Human error bugs go to zero for Rust code.
    • john_the_writer 1y ago
      Agreed. I rather dislike the idea of "safe" coding languages. Fighting with a memory leak in an elixir app, for the past week. I never viewed c or c++ as unsafe. Writing code is hard, always has been, always will be. It is never safe.
      • simonask 1y ago
        This is a bit of a misunderstanding. Safe code is just code that cannot have Undefined Behavior. C and C++ have the concept of "soundness" just like Rust, just no way to statically guard against it.
        • gcr 1y ago
          Modern compilers like clang and GCC both have static analysis for some of this. Check out the undefined behavior sanitizer.
          • humanrebar 1y ago
            Sanitizers are technically dynamic analysis. They instrument built programs and analyze them as they run.
          • deleted 1y ago
            [deleted]
          • simonask 1y ago
            As the other person pointed out, these are two different things. Sanitizers add runtime checks (with zero consideration for performance - don’t use these in productions). Static analysis runs at compile time, and while both GCC and Clang are doing amazing jobs of it, it’s still very easy to run into trouble. The mostly catch the low-hanging fruit. The technical reason is that Rust-the-language gives the compiler much more information to work with, and it doesn’t look like it is possible to add this information to the C or C++ languages.
        • rileymat2 1y ago
          There is more than undefined behavior, if I was to define using an uninitialized variable as yielding whatever data was previously in that location, it is well defined but unsafe.
          • oconnor663 1y ago
            That could be well defined for POD types like arrays of bytes (I think in that case they call it "freezing"), but you'd still have undefined behavior if the type in question contained pointers. Also at least in Rust it's UB to create illegal values of certain types, like a bool that's anything other than 0 or 1. Which is all kind of to say, all of Rust's different safety rules end up being surprisingly densely interconnected. It's really hard to guarantee one of them (say "no use-after-free") without ultimately requiring all of them ("no uninitialized variables", "no mutable aliasing", etc).
      • jen20 1y ago
        A memory leak is not a memory safety issue.
        • rileymat2 1y ago
          No, but it can be dangerous when you run out of memory for critical systems.
          • vrighter 1y ago
            yes, but that is neither here nor there. You can create a memory leak perfectly cromulently in rust too
  • hnlmorg 1y ago
    Heartbleed was a great demonstration of critical systems that were under appreciated. Too few maintainers, too few security researchers and too little funding. When writing systems as complicated and as sensitive as the leading encryption suite used globally, no language choice will save you from under resourcing.