Use the []byte slice to fill your Table, and use the simplest possible encoding, which uses as few constraints as possible: 1. Attrs on a line, separated by space, k-v separated by colon; 2. Each Entry on a separate line, have the fields encoded as in 1. 3. Decide how often do you want to fill Child - you can encode it as a number (position in the Entries list); 4. What should/could be in Data? Or maybe a nil/not-nil is enough for your code to be excercised?
Filling with garbage is better than erroring out on filling! matt....@gmail.com a következőt írta (2021. február 8., hétfő, 22:07:39 UTC+1): > 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/c068a29f-8ade-4882-bb88-4cd024f3e87dn%40googlegroups.com.
