SetMaxElements equivalent for msgp.Unmarshaler interface

[ajgajg1134]

Hello!

I saw the recent update included support for setting the max elements (and a few other protections) for the reader based interface. Would you be open to adding this support via the generated code for the other msgp.Unmarshaler interface?

This would be useful for me in enabling fuzz testing where we make use of the msgp.Unmarshaler interface for performance reasons. Without these limits today fuzz testing isn't feasible as random inputs that allocate huge amounts of memory crash / stall the fuzzer.

I had a couple ideas on how one (possibly me?) could go about implementing this, but none stood out to me as "obviously the best"

• Add package variables to the generated code that can be set at runtime to limit the sizes of allocated slices/dicts/strings etc (These would be overriden by any value set in the "Reader" if that is being used)
• Add an option to the code generation itself where a fixed value is provided at compile time

I'm happy to give more details if needed, Thanks!

[klauspost]

@ajgajg1134 You are welcome to write a PR proposal.

package variables

Generation is per file. These would have to be per-file const (unique_id)ArrayLimit = math.MaxUint32, etc. You can make a directive //msgp:arrayLimit n to override the default. Same for maps.

I don't see any reasonable way to make this runtime configurable.

There is no way to protect against recursion, if you have recursive types. But slice/map allocs are the biggest issues. In overall terms the overhead of using a Reader shouldn't be too big, so if content is untrusted use that.

[klauspost]

See #419

[klauspost]

@ajgajg1134 I also added custom struct field member limits.