search

rust-fuzz / honggfuzz-rs

Fuzz your Rust code with Google-developed Honggfuzz !
https://crates.io/crates/honggfuzz
Apache License 2.0
460 stars 42 forks source link

Adjust for changed error types in arbitrary crate #15

Closed ghost closed 6 years ago

ghost commented 6 years ago

The current version 0.2 of the arbitrary crate seems to have changed some error types so that the current code that is generated by the fuzz! macro does not compile.

This changes the code to be independent of the errors types and also adds arbitrary as a re-exported dependency so that its usage is fully transparent to users of this crate.

PaulGrandperrin commented 6 years ago

Hi @adam-rhebo, thanks for this PR! closes #13 bors r+

bors[bot] commented 6 years ago

Build succeeded

PaulGrandperrin commented 6 years ago

@adam-rhebo I just released 0.5.34 with your PR merged!

ghost commented 6 years ago

@adam-rhebo I just released 0.5.34 with your PR merged!

Thank you very much!

ghost commented 6 years ago

@PaulGrandperrin Sorry if I hijack this thread: But I just noticed something when testing this: When I noticed this not working with the current arbitrary, I open-coded the this but used FiniteBuffer instead of RingBuffer to create Vec<Vec<u8>>. The same fuzz target got around 10000 iterations per second with that approach, but running it now using RingBuffer I only get around 100 iterations per second. Could that be because FiniteBuffer just fails to create these vector of vectors when "the numbers don't match" and I now see the real speed without the early returns or is there some fundamental difference to how these work?

ghost commented 6 years ago

(I guess I should rather generate [Vec<u8>; N] to avoid this getting out of hand. With that approach, my iterations are back to normal.)