Your post doesn't address my question (and neither do any of the others replies). The article says:
> If the data can’t be parsed into a valid TLV, instead of throwing it away, return a syntactically correct dummy TLV. This can be anything, as long as it can be successfully unpacked.
Is the syntactically correct dummy value the same each time? If so, how does that lead to new coverage?
If it's a different valid TLV value each time, then it's not really a dummy value, is it? In any case, why bother with this "if invalid replace with dummy" step? Why not generate/mutate a valid TLV value from the start?
> Is the syntactically correct dummy value the same each time? If so, how does that lead to new coverage?
Per my understanding, the dummy value is constant but is only used once (to create the first valid TLV). Everything after that is a mutation of the original value that, due to the custom mutator logic, is a valid TLV. The mutations are where new coverage comes from.
> In any case, why bother with this "if invalid replace with dummy" step? Why not generate/mutate a valid TLV value from the start?
I'm guessing to handle both when there are seed files that are already valid (which you'll want to use instead of a dummy value), and when there aren't any valid seed files.
> If the data can’t be parsed into a valid TLV, instead of throwing it away, return a syntactically correct dummy TLV. This can be anything, as long as it can be successfully unpacked.
Is the syntactically correct dummy value the same each time? If so, how does that lead to new coverage?
If it's a different valid TLV value each time, then it's not really a dummy value, is it? In any case, why bother with this "if invalid replace with dummy" step? Why not generate/mutate a valid TLV value from the start?