libafl_bolts: more rands improvements
#2096
Conversation
| @@ -92,7 +92,7 @@ where | |||
| fn mutator_mut(&mut self) -> &mut M; | |||
|
|
|||
| /// Gets the number of iterations this mutator should run for. | |||
| fn iterations(&self, state: &mut Z::State) -> Result<u64, Error>; | |||
| fn iterations(&self, state: &mut Z::State) -> Result<usize, Error>; | |||
There was a problem hiding this comment.
This changes the API a little, @tokatoka you know this code the best, anything against it?
|
I personally think having 64 and 32 bit behave differently is okay, especially for our primary use case / fuzzing, if it improves performance. When would it be a problem? |
It is often convenient to exchange seeds between different machines/processes, or save them for later exact reproduction of what happened. "Coloring" PRNG behavior and seeds depending on the platform sounds like a footgun, I don't know of any PRNG library that does that. Regarding speed, to put things in the perspective, taking an old AMD K7 from https://www.agner.org/optimize/instruction_tables.pdf: |
|
If we want to keep behavior consistent, why move the APIs to usize from u64? |
Continuing where #2086 left off.
As for faster 32-bit fallback for
fast_bound, I realized that it will make the values you get different on 32-bit and 64-bit machines (using the same PRNG seed), which sounds bad.We should either accept the slight speed penalty on machines without fast full-width 64-bit multiply, or say "gotta go fast" and accept the bias you get from 32-bit multiply version. I think favoring 64-bit platforms here is reasonable, since probably the vast majority of fuzzing is done on them.