On Sep 12, 2012, at 2:42 PM, Tom Davie < email@hidden> wrote: I just performed an *Analyze* on the latest version of sqlite, version 3.7.14, downloaded from http://sqlite.org. 61 issues
were found. I've pasted in several representative issues below. I can understand what's going on with some of them, but as a practical matter, how should one deal with this?
One should fix them.
SQLite has a huge number of unit tests and a reputation as extremely stable code. Because of this, I suspect most or all of the things found by the static analyzer aren’t actually problems.
(17) I get hundreds of compiler warnings when I compile SQLite. Isn't this a problem? Doesn't it indicate poor code quality?
Quality assurance in SQLite is done using full-coverage testing, not by compiler warnings or other static code analysis tools. In other words, we verify that SQLite actually gets the correct answer, not that it merely satisfies stylistic constraints. Most of the SQLite code base is devoted purely to testing. The SQLite test suite runs tens of thousands of separate test cases and many of those test cases are parameterized so that hundreds of millions of tests involving billions of SQL statements are run and evaluated for correctness prior to every release. The developers use code coverage tools to verify that all paths through the code are tested. Whenever a bug is found in SQLite, new test cases are written to exhibit the bug so that the bug cannot recur undetected in the future.
During testing, the SQLite library is compiled with special instrumentation that allows the test scripts to simulate a wide variety of failures in order to verify that SQLite recovers correctly. Memory allocation is carefully tracked and no memory leaks occur, even following memory allocation failures. A custom VFS layer is used to simulate operating system crashes and power failures in order to ensure that transactions are atomic across these events. A mechanism for deliberately injecting I/O errors shows that SQLite is resilient to such malfunctions. (As an experiment, try inducing these kinds of errors on other SQL database engines and see what happens!)
We also run SQLite using Valgrind on Linux and verify that it detects no problems.
So, to look at one example:
static int sqlite3OsRandomness(sqlite3_vfs *pVfs, int nByte, char *zBufOut){
return pVfs->xRandomness(pVfs, nByte, zBufOut);
}
// Issue: Access to field 'xRandomness' results in a dereference of a null pointer (loaded from variable 'pVfs’)
For example, this warning is only valid if the function is ever called with a NULL pVfs parameter. It’s pretty likely that it’s never called that way. (I don’t _think_ the analyzer is smart enough yet to find all the sites where that function is called and check for NULL parameter values; at least not across multiple source files.)
Now, I _have_ run into several genuine bugs in open-source libraries using the static analyzer. But there are also a lot of false positives. I think part of the reason lots of warnings show up in 3rd party code is that, as we write our own code in Xcode, we get used to running the analyzer and tweaking our code to make the warnings shut up (even if they weren’t really warning about actual problems.) But if you analyze a code-base that isn’t primarily built in Xcode, it hasn’t had those tweaks applied to it.
—Jens |