Defaulting to all-zeroes is unexpected

[SimonSapin]

When Unexpected runs out of input data, int_in_range always returns range.start() (in my case, zero). This appears to be deliberate (3819274, 1d2f653) but was very unexpected to me, especially when arbitrary::Error::NotEnoughData exists.

This turned out to be involved in an infinite loop bug: apollographql/apollo-rs#426

(FWIW I ran into this quickly because I’m using input bytes not from a fuzzer but from a fixed-seed PRNG in order to generate a deterministic benchmarking corpus. Because I don’t have a useful size_hint, I picked an… arbitrary… number of input bytes.)

Silently devolving into pretty much Default seems very bad when the point of this crate is to generate varied values. Would you consider reverting the decision not to exit early?

If not, is Unstructured::is_empty a good indicator that defaulting happened? (I could maybe try doubling the input size until is_empty() stays false after generating items)

[fitzgen]

We've had empirical results that suggest that this behavior results in better fuzzing performance and exploration of the input state space, so I don't really want to revisit the decision.

is Unstructured::is_empty a good indicator that defaulting happened?

Yes, you can use this method to determine when you're generators have consumed all the available entropy and will start to / have started to receive default values.

[SimonSapin]

Instead of padding with zeros, would it make sense to cycle through already-used entropy?

[fitzgen]

This was something that I considered in the past, but I think it makes mutation/reduction more difficult, since now mutating one byte doesn't make one change in the generated structure. For example, if you're trying to create a minimal reproducer, the one byte that causes the generator to generate the thing that triggers the bug could be tied to also generating another thing, and you'll never be able to reduce to the actual minimal reproducer.

wasm-opt -ttf (a Wasm test case generator that is part of the binaryen project) does this recycling of the input, and I've found that its made test case reduction very difficult when I've tried to reduce its inputs.

[mkforsb]

I also got surprised by this. Maybe there could be something like an .int_in_range_checked() that checks if there's enough data? If nothing else, the doc comment could be changed to remove the rather strong suggestion that the operation will produce an error if there's not enough data.