Why Is SQLite Coded in C and not Rust

Re:Why Is SQLite Coded in C and not Rust by Ferret7446 on Tuesday October 14, 2025 @10:26PM (#45587433)

> Any language, including C, will emit or not emit instructions that are "invisible" to the author

Presumably this is why they do 100% test coverage. All of those instructions would be tested and not invisible to the test suite

[ Parent | on HN ]

Re:Why Is SQLite Coded in C and not Rust by cogman10 on Wednesday October 15, 2025 @07:03AM (#45590623)

How could they know? Any changes to the compiler will potentially generate new code.

A new compiler, new flags, a new version. These all can create new invisible untested branches.

[ Parent | on HN ]

Re:Why Is SQLite Coded in C and not Rust by joshkel on Wednesday October 15, 2025 @08:16AM (#45591225)

The way you know is by running the full SQLite test suite, with 100% MC/DC coverage (slightly stricter than 100% branch coverage), on each new compiler, version, and set of flags you intend to support. It's my understanding that this is the approach taken by the SQLite team.

Dr. Hipp's position is paraphrased as, “I cannot trust the compilers, so I test the binaries; the source code may have UBs or run into compiler bugs, but I know the binaries I distribute are correct because they were thoroughly tested" at https://blog.regehr.org/archives/1292. There, Dr. John Regehr, a researcher in undefined behavior, found some undefined behavior in the SQLite source code, which kicked off a discussion of the implications of UB given 100% MC/DC coverage of the binaries of every supported platform.

(I suppose the argument at this point is, "Users may use a new compiler, flag, or version that creates untested code, but that's not nearly as bad as _all_ releases and platforms containing untested code.")

[ Parent | on HN ]