public interface IFuzzDomainHow one target's inputs are made, when bytes are the wrong thing to mutate.
Remarks
The byte mutator is the right tool for a decoder and the wrong one for a compiler. Mutator's havoc is aimed at length prefixes and varints, and it is very good at those; pointed at a language it spends effectively all of its budget on text that does not lex. A shader that fails at its first token exercises the tokeniser and nothing behind it, so the binder, the type checker and the backend — which is where a compiler's interesting defects are — are never reached at all.
What changes is only how the next input is produced. Everything else is untouched and deliberately so: Run still takes a ReadOnlySpan<byte>, FuzzSession still measures allocation, time and retention around that one call, the corpus is still bytes on disk, and a FuzzFinding still carries the exact bytes that broke something. The four oracles are statements about behaviour, not about input shape, and a seam that made them care what an input is would have thrown away the only reason to grow this harness rather than adopt SharpFuzz.
Implemented as FuzzDomain`1 in practice. This interface is what the session sees, and it is byte-in byte-out precisely so that the session learns nothing about trees.
Fields and properties (1)
string WhatWhat is being mutated, in one line, for a report.
Methods (2)
byte[] Mutate(ReadOnlySpan<byte> input, ReadOnlySpan<byte> other, FuzzRandom random)Produces a mutant of an input, possibly drawing on another.
byte[] Fresh(FuzzRandom random)Produces an input from nothing.
Used by (5)
- FuzzDomainVixen.Fuzz
- FuzzSessionVixen.Fuzz
- IFuzzTargetVixen.Fuzz
- RavenTargetVixen.Fuzz
- VxmlTargetVixen.Fuzz