Open oyvindln opened 6 years ago
FWIW the fuzzing corpus added in #31 already includes files that trigger identical execution paths, according to cargo-fuzz instrumentation anyway. It might be a better idea to check the fuzzing corpus instead, or even better, run the fuzzer as a CI task.
We could probably do both, with the tests being mainly focused on checking that we return the correct error codes for the various forms of bogus input. I've already added in a bunch of them.
zlib-ng has a bunch of tests to check for among other things previous zlib vulnerabilities, and to provide good coverage of the library.
It would be useful to do port these tests to check that miniz_oxide won't panic on these specific inputs.
As they are zlib-licensed we may want to put the tests in separate files if possible and maybe exclude them from the crate upload, not sure how zlib and mit licenses interact (though the tests won't be a part of the final library obviously).