fix(Unstructured)!: don't produce meaningless data if exhausted #108
Conversation
If the Unstructured is completely exhausted, returning a buffer completely filled with zeroes instead of indicating failure does not make sense. It also causes issues for any users of Arbitrary implementations for integers (which are based on this method) who rely on eventually getting a nonzero result to e.g. break recursion.
Because the enum variant is decided based on an integer, and integers' Arbitrary implementations always returned 0 if the Unstructured was exhausted, an enum with a recursing first variant would lead to unbounded recursion.
|
Do you have any measurements of how this affects fuzzing quality? Failing to produce any data sounds like we'd end up running a huge number of test runs that fail at producing a type out of input bytes. |
|
No, I don't have any data on this. Instinctively I would say that returning "fake" data instead of erroring may be faster in the short term, but would mean that the fuzzer takes a long time until it finds an input long enough to actually produce useful mutations. This just seemed like the most obvious culprit for #107, though I supposed it could be worked around in other ways as well. |
|
We intentionally chose this behavior because empirically it helped See the commit message in 1d2f653 for some more details. |
|
Do you have a better idea for a fix for #107 then? |
|
@fitzgen |
If the
Unstructuredis completely exhausted, returning a buffer completely filled with zeroes instead of indicating failure does notmake sense. It also causes issues for any users of
Arbitraryimplementations for integers (which are based on this method) who rely on eventually getting a nonzero result to e.g. break recursion.Fixes #107.