fix: make sure ConsumeIntegralInRange is always in range [min; max]

[oetr]

No description provided.

[fmeum]

Can this change the result in any case in which it previously fell within the given bounds? If possible, we should avoid invalidating existing crashing inputs that behaved as expected.

[oetr]

Can this change the result in any case in which it previously fell within the given bounds? If possible, we should avoid invalidating existing crashing inputs that behaved as expected.

Ahh, I see what you mean, good point. And yes, it can and it will!
Obviously, this will still invalidate the crashes due to the bug addressed in this PR.
For ranges [0; N] (the most frequent in my opinion!) my change does nothing different.
For all other ranges it might invalidate the crashing input.

My motivation for leaving the number as is, if it's already within the requested range [min; max], was to make the fuzzer more efficiently use the table of recent compares.
The way I understand it, libfuzzer keeps recently compared numbers in a table and randomly inserts them during mutation steps.
If these numbers are reduced modulo some range, ToRC becomes mostly useless for ranges other than [0;N].
The further away the range deviates from [0; N], the more useless the ToRC becomes (IMO).

So, my claim is that this change makes fuzzing more efficient, but I don't have the data!

A compromise solution that considers your point and fixes the bug at the same time would be to always squeeze (aka remove the if-statement)

// if (range != std::numeric_limits<T>::max()) 
// We accept modulo bias in favor of reading a dynamic number of bytes as
// this would make it harder for the fuzzer to mutate towards values from
// the table of recent compares.
result = result % (range + 1);

return static_cast<T>(min + result);

If possible, we should avoid invalidating existing crashing inputs that behaved as expected.

It's inconvenient, but can be addressed by fixing the issues before upgrading to the new Jazzer release, or by running the fuzzer and letting it find the issue again.

WDYT?

[Copilot]

Pull Request Overview

This PR fixes a bug in the ConsumeIntegralInRange function to ensure the returned value is always within the specified range [min, max]. The fix optimizes for fuzzer effectiveness by preserving values that are already in range to maintain compatibility with the table of recent compares.

Key changes:

• Adds a check to return values already within range without modification
• Consolidates the modulo operation and range adjustment into a single expression
• Removes the conditional check for std::numeric_limits<T>::max()

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}