2 ms·
> 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 t
by Ferret7446 1y ago
> 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
- cogman10 1y agoHow 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.
- joshkel 1y agoThe 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 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.")