
OSS-Fuzz: Five months later, and rewarding projects - tanin
https://opensource.googleblog.com/2017/05/oss-fuzz-five-months-later-and.html
======
the_why_of_y
Interesting that they managed to find 8 security bugs in SQLite, which is
renowned for having a test suite with ~100% code coverage - yet more evidence
for the Dijkstra dictum that testing cannot prove the absence of bugs.

[https://sqlite.org/testing.html](https://sqlite.org/testing.html)

~~~
obstinate
100% test coverage is an ambiguous term. Is it line coverage, branch coverage,
and do the branches include arithmetic nonlinearity branches and exception
flags? Are all possibly syscall error states tested?

One hundred percent line coverage is admirable, but it's just a start! (Edit:
I see that they had far more than just 100% line coverage, but as you can see
even this is not enough to find all cases.)

~~~
masklinn
> 100% test coverage is an ambiguous term. Is it line coverage, branch
> coverage

The linked document answers that both repeatedly and at length:

> The SQLite core, including the unix VFS, has 100% branch test coverage under
> TH3 in its default configuration as measured by gcov.

[follow half a dozen paragraph explaining what they mean precisely by branch
coverage]

~~~
obstinate
And my edit denotes that I saw that and acknowledged it! :)

~~~
Dor1s
Even with 100% coverage, there might be the following code (just a one of
numerous examples):

char buffer[15];

.....

memcpy(buffer, source, strlen(source));

Depending on the `source`, the bug can be triggered or not, but the coverage
is the same for different `source` values.

