On 12/12/19, Arthur Blondel <arthur5blon...@gmail.com> wrote:
> I'm using amalgamation version 3.30.1. and check with CodeSonar
I've never heard of CodeSonar before. It appears to be some kind of
static analysis tool that reads the source code and tries to infer
potential problems. These tools are usually pretty weak, giving lots
of false-positives. CodeSonar seems to fall into the general pattern.
Authur sent me a spreadsheet with 432 warnings (not 32000 as
originally mentioned). Let's take the last one as an example. The
information I have is:
"Use of strlen" sqlite3.c:117554
The line of code it is concerned about is here:
https://www.sqlite.org/src/artifact/40557ebd69f4115e?ln=152
Note: sqlite3Strlen30NN() used to be a real function, but we later
changed it into a macro for performance reasons. The definition is:
#define sqlite3Strlen30NN(C) (strlen(C)&0x3fffffff)
The tool does not provide any details beyond "Use of strlen". Perhaps
it is concerned that the input pointer zColAff is NULL. The assert()
on the previous line show that concern to be misplaced. But even
without the assert(), if you trace the logic in this one function, you
clearly see that there is no possible way for zColAff to be NULL. Of
course, reasoning that through is probably beyond the limited
capabilities of CodeSonar, and so it raised the warning.
Perhaps the concern is that the zColAff string is not zero-terminated.
That case is more difficult to reason about. If the code between
lines 135 to 149 runs, then zColAff will clearly be zero-terminated,
but what if that logic is skipped? Who is to say that the string
initially in pTab->zColAff is zero-terminated? Answering that
question requires a global analysis. If you examine the rest of the
source code, you find that the *only* place where pTab->zColAff is
ever set is in this one function, and hence pTab->zColAff must always
be zero-terminated.
So any way you look at it, this is a false-positive warning.
And false-positive warnings like this are typical of static analysis
tools. Indeed, static analysis tools have never proven helpful in
finding problems in SQLite. SQLite uses more advanced techniques such
as 100% MC/DC testing, run-time analysis, and the latest
profile-guided fuzzing methods. This is not to say that SQLite is
100% bug-free. (It isn't.) But I do claim that the kinds of bugs
that remain in SQLite are way, way beyond the ability of CodeSonar to
detect.
I have not looked at any of the other 441 warnings that Arthur sent,
as my prior experience with these things tells me that they are likely
to all be false-positives. Time spent analyzing the other 441
warnings is time that I am not using more advanced methods that have a
much higher probability of finding real errors. So I'm going to
ignore the rest of the CodeSonar warnings and focus on more productive
pursuits.
If anybody else wants to have a look, the list of warnings can be seen
at https://sqlite.org/tmp/codesonar_warnings.csv
--
D. Richard Hipp
d...@sqlite.org
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
