Posted by Jeffrey Walton on Apr 20

Clang and its analyzers found a number of issues a couple of years
ago. As far as I know, the results were dismissed. See “Clang 3.3 and
Scan-Build results”,
http://sqlite.1065341.n5.nabble.com/Clang-3-3-and-Scan-Build-results-td73386.html.

Posted by Jeffrey Walton on Apr 20

I’ve felt the pain myself. So I’m definitely in the sympathize camp.

Yeah, its a trade off.

We know developers are smarter than the analyzers. But rather than
developers working with the analyzers – like initializing a variable
even if it does not need to be done (and letting the optimizer do its
job) – they just dismiss all the results. They dismiss both the valid
ones and the noise. Its a very disingenuous strategy.

Its no wonder…

Posted by jungle Boogie on Apr 20

Richard and the team certainly have been busy bees:
https://www.sqlite.org/src/timeline?n=152&y=ci&v=0&ym=2015-04&t=trunk

And all commits by month:
https://www.sqlite.org/src/reports?view=bymonth&type=ci

Posted by jungle Boogie on Apr 20

Just curious if you have tried your great tool on the other database
projects like mysql/maiadb and postgresql, so are they not suitable
for fuzzing?

Posted by Michal Zalewski on Apr 20

Well, I can kinda sympathize. Somebody took one of my OSS projects
(p0f) and ran it through a static analyzer a while ago (the analyzer
shall remain nameless, but was one of the major ones). The results
were just pages and pages of nonsensical findings, interspersed with
non-specific style recommendations.

An experience like that can quickly divide developers into two camps:
the “not sure, but let me spend a week to address everything, just…

Posted by Michal Zalewski on Apr 20

Yup. In addition to the crashes, I also sent them probably around
50-60 assert failures in debug builds, at their request. Most of them
are probably not security relevant, although it would be painful to
analyze them one by one. Nevertheless, the team is extremely
responsive (even over weekends :-).

/mz