Currently, stochastic fuzzer flags are always re-computed when evaluated. There is no way to persist the truth value of a fuzzer flag across a run of the fuzzer.
This causes problems when, for instance, the flag needs evaluating when checking availability of an action, and then evaluating again when constructing its payload. If the flag sets availability to true but then prevents payload generation, this would cause an error. Right now, the only thing to do is be pessimistic in the availability pass: if the flag has a probability distribution other than 1 or 0, then assume the flag takes the value that is most likely to stop availability.
Ideally, there should be a way to 'fix' the value of a fuzzer flag in the availability check, and then use that fixed value in the payload generator. This would likely involve constructing a state monad for both stages to share, and is not a particularly trivial task.
Currently, stochastic fuzzer flags are always re-computed when evaluated. There is no way to persist the truth value of a fuzzer flag across a run of the fuzzer.
This causes problems when, for instance, the flag needs evaluating when checking availability of an action, and then evaluating again when constructing its payload. If the flag sets availability to true but then prevents payload generation, this would cause an error. Right now, the only thing to do is be pessimistic in the availability pass: if the flag has a probability distribution other than 1 or 0, then assume the flag takes the value that is most likely to stop availability.
Ideally, there should be a way to 'fix' the value of a fuzzer flag in the availability check, and then use that fixed value in the payload generator. This would likely involve constructing a state monad for both stages to share, and is not a particularly trivial task.