4 ms·

> Had SQLite ever had a memory leak or use-after-delete bug on a production release? sure, it's an old library they had pretty much anything (not because they

> Had SQLite ever had a memory leak or use-after-delete bug on a production release? sure, it's an old library they had pretty much anything (not because they don't know what they are doing but because shit happens) lets check CVEs of the last few years: - CVE-2025-29088 type confusion - CVE-2025-29087 out of bounds write - CVE-2025-7458 integer overflow, possible in optimized rust but test builds check for it - CVE-2025-6965 memory corruption, rust might not have helped - CVE-2025-3277 integer overflow, rust might have helped - CVE-2024-0232 use after free - CVE-2023-36191 segmentation violation, unclear if rust would have helped - CVE-2023-7104 buffer overflow - CVE-2022-46908 validation logic error - CVE-2022-35737 array bounds overflow - CVE-2021-45346 memory leak ... as you can see the majority of CVEs of sqlite are much less likely in rust (but a rust sqlite impl. likely would use unsafe, so not impossible) as a side note there being so many CVEs in 2025 seem to be related to better some companies (e.g. Google) having done quite a bit of fuzz testing of SQLite other takeaways: - 100% branch coverage is nice, but doesn't guarantee memory soundness in C - given how deeply people look for CVEs in SQLite the number of CVEs found is not at all as bad as it might look but also one final question: SQLite uses some of the best C programmers out there, only they merge anything to the code, it had very limited degree of change compared to a typical company project. And we still have memory vulnerabilities. How is anyone still arguing for C for new projects?

oguz-ismail 1y ago
> How is anyone still arguing for C for new projects? It just works
- krior 1y ago
  That list alone sounds like it does not work.
  - uecker 1y ago
    As long as it is possible to produce a OOB in something as simple as a matrix transpose, Rust also does not work: https://rustsec.org/advisories/RUSTSEC-2023-0080.html https://rustsec.org/advisories/RUSTSEC-2023-0080.html.
    - dwattttt 1y ago
      While a package with 10 million all-time downloads is nothing to sneeze at, it's had one memory corruption bug reported in its ~7 year life. It's being compared to a C library that's held to extremely high standards, yet this year had two integer overflow CVEs and two other memory corruption CVEs. SQLite is a lot more code, but it's also been around a lot longer.
      - uecker 1y ago
        The point is that matrix transpose should be trivial. But my main point really is that looking at CVEs is just nonsense. In both cases it is is a rather meaningless.
        dathinab 1y ago
        except that if you read into the actual issue you will realize that transposing matrices high performant is surprisingly not trivial, e.g. see this code code: https://github.com/ejmahler/transpose/blob/e70dd159f1881d86aa50ee01586d04e7a83d8dbe/src/in_place.rs#L69-L71 https://github.com/ejmahler/transpose/blob/e70dd159f1881d86a... furthermore the issue at core was an integer overflow, which is tricky in all languages and e.g. has poppet up on HN recently in context of "proven correct" code still having bugs (because the prove didn't use finit precision integers) it's also less tricky in rust then in C due to no implicit casts and debug build checking for integer overflows and tests normally running against debug builds Projects do sometimes enable it even on release builds for security sensitive code(1). so if anything the linked issue is in favor of using rust over C while acting as a reminder that no solution is perfect (1): It comes at a high performance cost, but sometimes for some things it's an acceptable cost. Also you can change such setting per crate. E.g. at a company I worked at a few years ago we did build some sensitive and iffy but not hot parts always with such checks enabled and some supper hot ML parts always with optimizations enabled even for "debug/test" builds.
        uecker 1y ago
        Bounds checking for matrices is trivial. The point is that once you compete with C and need to do something slightly more complex, mistakes also can happen in Rust. Now, we can have a discussion if it is still safer and I may even agree), but it defeats the "eliminate a whole class of issues" marketing, doesn't it?
- saghm 1y ago
  If your definition of "works" includes out of bounds memory access, use after free, etc., then yes. If your definition does not include those, then it demonstrably does not. Alternately, maybe there's a spectrum of undesirable behaviors, some of which are preventable by choice of language, some of which aren't, and trying to reduce a complex set of tradeoffs to a simple binary of whether it "just works" only restates the conclusion someone has already come to because you need to actually reason about those tradeoffs to come to an informed decision of where to implicitly draw the line in the first place.
daxfohl 1y ago
Wow that's a great analysis! Yeah I essentially agree. I'm sure there are still plenty of good cases for C, depending on project size, experience of the engineers, integration with existing libraries, target platform, etc. But it definitely seems like Rust would be the better option in scenarios where there's not some a priori thing that strongly skews toward or forces C.

oguz-ismail 1y ago

> How is anyone still arguing for C for new projects? It just works

krior 1y ago
That list alone sounds like it does not work.
- uecker 1y ago
  As long as it is possible to produce a OOB in something as simple as a matrix transpose, Rust also does not work: https://rustsec.org/advisories/RUSTSEC-2023-0080.html https://rustsec.org/advisories/RUSTSEC-2023-0080.html.
  - dwattttt 1y ago
    While a package with 10 million all-time downloads is nothing to sneeze at, it's had one memory corruption bug reported in its ~7 year life. It's being compared to a C library that's held to extremely high standards, yet this year had two integer overflow CVEs and two other memory corruption CVEs. SQLite is a lot more code, but it's also been around a lot longer.
    - uecker 1y ago
      The point is that matrix transpose should be trivial. But my main point really is that looking at CVEs is just nonsense. In both cases it is is a rather meaningless.
      - dathinab 1y ago
        except that if you read into the actual issue you will realize that transposing matrices high performant is surprisingly not trivial, e.g. see this code code: https://github.com/ejmahler/transpose/blob/e70dd159f1881d86aa50ee01586d04e7a83d8dbe/src/in_place.rs#L69-L71 https://github.com/ejmahler/transpose/blob/e70dd159f1881d86a... furthermore the issue at core was an integer overflow, which is tricky in all languages and e.g. has poppet up on HN recently in context of "proven correct" code still having bugs (because the prove didn't use finit precision integers) it's also less tricky in rust then in C due to no implicit casts and debug build checking for integer overflows and tests normally running against debug builds Projects do sometimes enable it even on release builds for security sensitive code(1). so if anything the linked issue is in favor of using rust over C while acting as a reminder that no solution is perfect (1): It comes at a high performance cost, but sometimes for some things it's an acceptable cost. Also you can change such setting per crate. E.g. at a company I worked at a few years ago we did build some sensitive and iffy but not hot parts always with such checks enabled and some supper hot ML parts always with optimizations enabled even for "debug/test" builds.
        uecker 1y ago
        Bounds checking for matrices is trivial. The point is that once you compete with C and need to do something slightly more complex, mistakes also can happen in Rust. Now, we can have a discussion if it is still safer and I may even agree), but it defeats the "eliminate a whole class of issues" marketing, doesn't it?
saghm 1y ago
If your definition of "works" includes out of bounds memory access, use after free, etc., then yes. If your definition does not include those, then it demonstrably does not. Alternately, maybe there's a spectrum of undesirable behaviors, some of which are preventable by choice of language, some of which aren't, and trying to reduce a complex set of tradeoffs to a simple binary of whether it "just works" only restates the conclusion someone has already come to because you need to actually reason about those tradeoffs to come to an informed decision of where to implicitly draw the line in the first place.

daxfohl 1y ago

Wow that's a great analysis! Yeah I essentially agree. I'm sure there are still plenty of good cases for C, depending on project size, experience of the engineers, integration with existing libraries, target platform, etc. But it definitely seems like Rust would be the better option in scenarios where there's not some a priori thing that strongly skews toward or forces C.