mirror of https://github.com/google/oss-fuzz.git
af03d10626
As discussed in the original PR#588, it may be better to start with empty corpus, and see what happens. Even though i have the full corpus set to get full (80%+) coverage, it is quite likely to result in horrible performance. Currently, the library is built with no external dependencies - jpeg, zlib - not too sure if it makes sense to fuzz those indirectly. And if i can built zlib in-tree, building jpeg in-tree will be more complicated because it does not have CMake build system. As you can see, more than one fuzzing target is provided. The RawSpeedFuzzer is the most global one, it will be able to eventually cover all the code, others are more fine-grained, and will only be able to cover some small portion of the code. Thus, i suppose both the performance and the coverage may win. I did test this locally. Both the address and the undefined configurations work. |
||
|---|---|---|
| .. | ||
| Dockerfile | ||
| build.sh | ||
| project.yaml | ||