-
-
Notifications
You must be signed in to change notification settings - Fork 403
Introduce StateAwareMappingMutator #3437
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce StateAwareMappingMutator #3437
Conversation
(CI failures seem unrelated) |
#3454 should fix the CI |
/// | ||
/// Allows using [`Mutator`]s for a certain type on (parts of) other input types that can be mapped to this type. | ||
/// | ||
/// For a more flexible alternative, which allows access to `state`, see [`StateAwareMappingMutator`]. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason not to always use the StateAware version?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not really, besides having to ignore parameters and having to wrap your results in Some
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So can we get rid of some duplicate code or should I just merge? :D
Description
Sometimes, one needs access to
state
(e.g. for its RNG) in a mapper.StateAwareMappingMutator
provides this functionality.This PR also creates user-friendly functions to use it with havoc and numeric mutators, and adds example code to the demo fuzzer.
Checklist
./scripts/precommit.sh
and addressed all comments