-
-
Notifications
You must be signed in to change notification settings - Fork 367
Introduce BoolMutator #2926
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 BoolMutator #2926
Conversation
thank you |
I don't know where (if anywhere?) my comments ended up: |
For any other datatype, I'd agree, but for bools this doesn't make much sense imo. It would result in a mutator that does the same as the current If you want a mutator that only sometimes works, wrap your mutator in another which will filter some of the invocations.
Or are you thinking about a mutator that somehow receives a bool instead of operating on one? Am I misunderstanding you? |
It does make perfect sense, it mutates a bool to a random value. At least rename that dude to |
Can you rename it? :) |
To me, mutation implies something changed. And while most other mutators don't guarantee this because of performance reasons (I think we discussed this in another issue at some point), here we can. The randomness in most LibAFL-based fuzzers of whether or not the bool in an input is mutated is provided by the mutation scheduler. And there, any non-trivial implementation (so not just random selection or round-robin) will likely work better if mutation happens consistently, and even for trivial implementation, it will just slow the fuzzer down because additional rounds of mutation need to be done or the target is unnecessarily executed with an unchanged input. I prefer the simple |
|
I agree that BoolMutator can be both: "Just change that bool" (i.e., invert) or "Randomize that bool".. |
Useful for complex input types containing booleans in combination with
MappingMutator
s.