dummy hotfix for min/max vec lengths during mutation

[sadeli413]

This adds a naive hotfix for the min/max length constraints for a vec during mutation and (partially) addresses #2.
The downside to my patch is that it may give preferential weight to the far min/max bound.

use lain::prelude::*;
use lain::rand;

#[derive(Debug, Mutatable, NewFuzzed, BinarySerialize)]
struct MyStruct {
    #[lain(min = 5, max = 7)]
    field: Vec<u32>,
}

fn main() {
    let mut mutator = Mutator::new(rand::thread_rng());
    let mut instance = MyStruct::new_fuzzed(&mut mutator, None);

    // Ignore this, initialization is broken atm
    while !(5..=7).contains(&instance.field.len()) {
        mutator = Mutator::new(rand::thread_rng());
        instance = MyStruct::new_fuzzed(&mut mutator, None);
    }

    for _ in 0..1000 {
        instance.mutate(&mut mutator, None);
        assert!((5..=7).contains(&instance.field.len()));
    }
}

[jma-qb]

Hi, I have a few comments as I also tried to fix this.

• to complete this you should have a look at https://github.com/AFLplusplus/lain/blob/main/lain/src/mutatable.rs#L44 and make sure the max bound is taken into account when growing an empty Vec
• I think you can hit the condition https://github.com/AFLplusplus/lain/blob/main/lain/src/mutatable.rs#L150 with a min size > 0 (it happened to me but my patch was slightly different) so you should add a check to do it only when the minimal size is 0
• you are missing this fix https://github.com/microsoft/lain/pull/6/files#diff-79581a1c35413987e75ecf7e6ffa1df8f79c0b2abb9f152fbcefac64056842f5R167 to which you should add a comparison with the min size.

[sadeli413]

Doesn't the patch already fix these three issues?

make sure the max bound is taken into account when growing an empty Vec

The max bound will be constrained by this regardless if the vec is empty or not: https://github.com/AFLplusplus/lain/pull/3/files#diff-79581a1c35413987e75ecf7e6ffa1df8f79c0b2abb9f152fbcefac64056842f5R59

I think you can hit the condition ... with a min size > 0

This makes sure that num_elements will never equal vec.len() if min_size > 0: https://github.com/AFLplusplus/lain/pull/3/files#diff-79581a1c35413987e75ecf7e6ffa1df8f79c0b2abb9f152fbcefac64056842f5R152

you should add a comparison with the min size

The comparison with the min size is already here: https://github.com/AFLplusplus/lain/pull/3/files#diff-79581a1c35413987e75ecf7e6ffa1df8f79c0b2abb9f152fbcefac64056842f5L146-R154

I'm probably missing something so lmk if you see more issues

[jma-qb]

My bad, you are right and all 3 points I raised were wrong. I ran some tests and there is no issue with the bounds.
But while testing it appears your patch is heavily biased toward generating empty Vecs when the min bound is 0. Could you try confirming it ?

[sadeli413]

Yep, can confirm. My patch has a bias toward the min and max bounds, since it just chops off values that go over the bounds instead of generating a length between those bounds. This will have to be fixed.

[domenukk]

This is probably fixed with #10 , right? CC @jma-qb

[sadeli413]

Yes! #10 fixes this.