3 ms·

> Going off topic, maybe someone will eventually do a SQLLite re-write as well and other critical projects to our modern stacks that still rely on C. SQLite do

by cyphar 10y ago

> Going off topic, maybe someone will eventually do a SQLLite re-write as well and other critical projects to our modern stacks that still rely on C. SQLite does not need to be rewritten. It has the best and most comprehensive test suite in the history of software development -- I would go so far as to say that there are no implementation bugs in SQLite (every single branch in the code has been extensively tested and also extensively tested with dummy failures and so on). So a rewrite in a safer language would benefit nobody (and would just be a huge time sink).

jjnoakes 10y ago
I'm not advocating one way or the other, but I will say that I don't believe 100% code coverage guarantees that you have no issues lurking that a safer language would prevent. Now it probably isn't worth the effort for a very well tested project like sqlite, but that doesn't validate the premise.
- cyphar 10y ago
  > but I will say that I don't believe 100% code coverage guarantees that you have no issues lurking that a safer language would prevent. It's 100% branch coverage, with 100% fault coverage as well. If there is an "issue lurking that a safer language would prevent" I would honestly be shocked. SQLite is not a good project to mention rewriting, because it is an incredible technical acheivement in terms of how well tested it is.
  - jjnoakes 10y ago
    > SQLite is not a good project to mention rewriting Which, as I said, is not what I'm doing. I'm only disagreeing with the premise that 100% test coverage means 0% chance of an unsafe bug existing in the code base (for any code base, not just for SQLite).
    - cyphar 10y ago
      Personally, I consider 100% branch coverage to mean an effectively 0% chance of an unsafe bug existing in the code base. Does Rust have 100% branch coverage in their compiler? So how can you be absolutely sure their compiler doesn't have bugs when doing borrow checking and other tomfoolery? 100% branch coverage is an _insanely_ high standard and you can't compare it to any other project unless that project also has 100% branch coverage or similar.

by cyphar 10y ago

jjnoakes 10y ago

I'm not advocating one way or the other, but I will say that I don't believe 100% code coverage guarantees that you have no issues lurking that a safer language would prevent. Now it probably isn't worth the effort for a very well tested project like sqlite, but that doesn't validate the premise.

cyphar 10y ago
> but I will say that I don't believe 100% code coverage guarantees that you have no issues lurking that a safer language would prevent. It's 100% branch coverage, with 100% fault coverage as well. If there is an "issue lurking that a safer language would prevent" I would honestly be shocked. SQLite is not a good project to mention rewriting, because it is an incredible technical acheivement in terms of how well tested it is.
- jjnoakes 10y ago
  > SQLite is not a good project to mention rewriting Which, as I said, is not what I'm doing. I'm only disagreeing with the premise that 100% test coverage means 0% chance of an unsafe bug existing in the code base (for any code base, not just for SQLite).
  - cyphar 10y ago
    Personally, I consider 100% branch coverage to mean an effectively 0% chance of an unsafe bug existing in the code base. Does Rust have 100% branch coverage in their compiler? So how can you be absolutely sure their compiler doesn't have bugs when doing borrow checking and other tomfoolery? 100% branch coverage is an _insanely_ high standard and you can't compare it to any other project unless that project also has 100% branch coverage or similar.