Dmitry Vyukov

This is an interesting one about reusing Fuzz function in unit tests: https://github.com/golang/go/issues/19109#issuecomment-280303794 A first idea is providing a FromT function that creates a stub F from testing.T to use...

Looking at libfuzzer flags in case there are others like -timeout which are actually test property: https://llvm.org/docs/LibFuzzer.html#options Potentially relevant may be: ``` -max_len Maximum length of a test input. If...

> > For Interesting maybe we want to pass an integer priority (how much it is interesting). But for most cases it will indeed be binary. Or maybe we want...

> > I am not sure it's Fuzz function responsibility to know about layout of files on disk. > > I agree, although I do think there should be a...

> This interacts with the Fuzz function signature: If you want some amount of resilience in your corpus (e.g. no changes required if you merely add a new input), then...

> func FuzzRegexp(f *testing.F, re string, data []byte, posix bool) Forgot to mention one thing. One very interesting direction is using struct field tags to provide more hints/semantic information to...

`testdata` already located in the package dir, why do we need package name second time in `pkg.FuzzFunc`? Could it be just `pkgpath/testdata/fuzz/FuzzFunc/corpus`?

I see. This allows to point -fuzzdir to a common location for _all_ targets/packages. Makes sense. A more principled approach would be to include full package path then. It would...

Another option is to just -fuzzdir as is and don't append anything. Then it's implied to be user (script, infrastructure) responsibility to pass proper paths in whatever convention they want....

> Would that imply a need to also drop FuzzFunc from the path? Or would OSS-Fuzz be OK with that? I can't confirm neither deny this. > Any thoughts on...