Add length range to FuzzInputOptions

[AdamGoertz]

Closes #20816

Example test case, fuzzing f64 printing.

test "fuzz example" {
    const Context = struct {
        fn testOne(context: @This(), input: []const u8) anyerror!void {
            _ = context;
            // Try passing `--fuzz` to `zig build test` and see if it manages to fail this test case!
            try std.testing.expect(!std.mem.eql(u8, "canyoufindme", input));
        }
    };
    try std.testing.fuzz(Context{}, Context.testOne, .{ .len_range = .{
        .min = 12,
        .max = 12,
    } });
}

The first run of the fuzzer is seeded with random bytes, with length equal to the minimum allowed length.

[andrewrk]

I'll look at this in a couple days - I have a rather large body of work sitting in the fuzz branch right now.

[AdamGoertz]

No problem, I figured. As of yesterday looks like the conflicts would be pretty minimal, so hopefully it'll stay easy.

[andrewrk]

Looks like there were indeed a couple of conflicts.

[AdamGoertz]

Conflicts resolved 👍

[andrewrk]

If the minimum length is greater than 0, the corpus must contain at least 1 entry, so that we can use it for the initial run/smoke test of the fuzzer.

No need, it can generate random bytes in this case.

[AdamGoertz]

If the minimum length is greater than 0, the corpus must contain at least 1 entry, so that we can use it for the initial run/smoke test of the fuzzer.

No need, it can generate random bytes in this case.

I considered this. The concern I had was with ownership of the memory for holding the input. Since the length range is runtime known we need to allocate it dynamically. Under normal circumstances the fuzzer owns all of the returned memory, but on the initial run it's not clear how to de-allocate the slice returned from fuzzInput. A few options I considered:

• Use a comptime-known length range:
  This would force the FuzzInputOptions parameter to be comptime known. Being able to load corpus entries from a file (without '@embedfile') would be nice, which this option would preclude. The length range could also be moved to a second parameter.

• Reorganize the fuzzer code so it is still able to manage the returned input even when not linked to libfuzzer: This might be the best option, but I haven't explored how difficult it would be. My objective was to minimize changes to the current fuzzing architecture.

• add a 'deinit' function for the fuzzer input: totally possible, just annoying because it would do nothing while actually fuzzing; its only responsibility would be cleaning up this one allocation for the smoke test.

Does one of these (or something else I haven't considered) seem like a better approach?

[AdamGoertz]

Ok, a pretty easy solution by adding another global variable to track the bytes allocated for the smoke test. I think that should work.

[andrewrk]

I think I've addressed your objection in #21370. After those changes, you can use std.testing.allocator to allocate the input buffer, and free it after the call to testOne.

[AdamGoertz]

Sounds good! Once that lands I'll take another look 👍

[AdamGoertz]

Looks like the updated version is now green 👍🏻