I don't have a really good answer for you, but just in case it helps, I asked a loosely related question on Twitter once: https://twitter.com/TheMerovius/status/1068459958256246784 It's a different problem, but maybe some of the follow-up links can still help?
In any case, please let me know if you find a satisfying answer at some point :) On Mon, Feb 8, 2021 at 10:08 PM Matt Proud <matt.pr...@gmail.com> wrote: > Hi all, > > I want to check the wisdom of the crowd on the following topic: > > Suppose I am interested in fuzz testing an API using dvyukov/go-fuzz > <https://github.com/dvyukov/go-fuzz>, and the primary API under test > accepts relatively complex composite data types itself: func F(*Table) > error, where the types below are minimally as complex as this: > > type Entry struct { > Name string > Date time.Date > Child *Entry // optional > Data interface{} // optional and user-defined > } > > type Table struct { > Attrs map[string]string > Entries []*Entry > } > > go-fuzz expects the fuzz entrypoints to be func Fuzz(data []byte) int, > meaning *Table cannot be used directly without some intermediate > serialization and deserialization. Suppose that *Table has no regular > on-disk format; what would you recommend as the approach to take toward > generating an initial corpus so that go-fuzz can explore the search space > and generate prospective crashers. > > I've toyed around a bit with taking representative values and encoding > them to disk with encoding/gob and then having go-fuzz deserialize, > validate, and reject bad gob value candidates by returning -1. > Notwithstanding any issues inherent to encoding/gob, this does not feel > like a particularly efficient on account of extraneous exercising of the > gob encoding format, when really func F(*Table) error is what I want to > exercise (as in commit my CPU cycles toward). > > Potentially there are a few other ways of encoding *Table, like Protocol > Buffers (with caveats), but encoding/binary is definitely out due to the > opaque size of *Table. The point still stands: I would ideally not want to > exercise the serialization flow so much as handling of the type on which > the data is projected. > > What strategy would you use here? I feel like there should be an obvious > choice under my nose that I am somehow omitting. And no, I don't want > testing/quick for this, even though it can generate plenty of complex > composite types at runtime. > > With warm regards, > > Matt T. Proud > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/802159d8-ae45-4758-ac57-3d800bdc406en%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/802159d8-ae45-4758-ac57-3d800bdc406en%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfG97DTEdAUKtQQwN%2BygmyJ5fnw%3DoD7_5ApG6FFrKdHW8g%40mail.gmail.com.
