Dmitry Vyukov

I don't mind. We could add some bold header, issue template and link them to native fuzzing page.

Yes, I think "Archiving' in the github sense is early (and unnecessary, at least at this point). There seems to be agreement on adding some note to the readme to...

I would move only the `AdditionalInheritedHandles` to separate files, the rest seems to be the same (?) so no need to duplicate. But otherwise looks good to me.

@josharian do you think it's possible to handle all possible consts in all contexts correctly? As far as I remember I just shuffled the code until it started compiling all...

Overall I am a fan of scripting expert smartness and making it available to all users out-of-the box, rather then shifting the hard work onto every user. We could do...

> I'm torn on the format; I like how it's simple, but it's not hard to imagine newline characters being useful in literals. One sloppy option is to stay line-oriented,...

Hi @turbolent, > Would it be possible to add support for it to go-fuzz's libFuzzer mode? Adding new significant features to go-fuzz today makes little sense in the light of...

It can make sense to start with allowing to select the fuzz function after building the package for fuzzing, namely as go-fuzz flag. Could we collect all possible fuzz functions...

Hi @marco-m I update the title and added an update to the description. Does it look better? Thinking of this, any serious project will most likely have >1 package as...

go-fuzz is being superseded by the standard toolchain: https://go.googlesource.com/proposal/+/master/design/draft-fuzzing.md https://github.com/golang/go/tree/dev.fuzz Any new development in go-fuzz beyond bug fixing does not make sense now.