I think that dependency on dvyukov/go-fuzz-corpus would need to be eliminated prior to putting go-fuzz-corpus/gif/gif.go into the standard library.

Agree.
I think we should use whatever would be considered the idiomatic solution for tests, tests do lots of such comparisons. There is no reason to do something different here. I think the idiomatic solution is to open-code all comparisons (?).

I'm happy to see that progress is being made, and I am willing to prepare these next CLs too, if that's okay with everyone.

It seems like of the three packages listed in this issue, gif requires the most attention:

First, there are two fuzz functions: a Fuzz and a FuzzAll. I assume both should be included. Do their names stay as they are?

Second, @dvyukov, what exactly do you mean by "open-code" all comparisons? Explicitly writing loops and such, and avoiding reflect.DeepEqual or similar?

First, there are two fuzz functions: a Fuzz and a FuzzAll. I assume both should be included. Do their names stay as they are?

I named them after the actual Encode/Decode functions. Seems fine to me.

Second, @dvyukov, what exactly do you mean by "open-code" all comparisons? Explicitly writing loops and such, and avoiding reflect.DeepEqual or similar?

Using != for scalars, strings; bytes.Equal for byte slices, etc. E.g.

if a.Foo != b.Foo {
  panic("bad Foo")
}
if !bytes.Equal(a.Bar, b.Bar) {
  panic("bad Bad")
}

Regarding this piece about FuzzAll for gif:

I think the idiomatic solution is to open-code all comparisons (?).

It seems image/src/gif/write_test.go has some logic around doing comparison, including in testEncodeAll. I have not looked carefully, but perhaps some or all of that logic could be reused for FuzzAll for gif.

I would like to bring to your attention the fact that building go-fuzz binaries for standard library packages (from inside the packages themselves, unlike dvyukov/go-fuzz-corpus) seems to be a little tricky. Perhaps these things are obvious in retrospect, but to me, they were not, at least initially.

Apart from GO111MODULE=off being necessary, the go that go-fuzz-build finds through exec.LookPath must be from the Go tree as the package being instrumented. In other words, go-fuzz-build image/png tries to build an instrumented binary for the image/png relative to the go it found in PATH. More concretely, ISTM that if you are looking to fuzz image/png from /some/place/go/src/image/png, you must arrange for /some/place/go/bin/go to be the first go in PATH, when you run go-fuzz-build.

I imagine that for people who do not use two different Go trees (one for general work using Go and another for working on Go itself), this is not a problem at all, but if you are like me and use different trees, you might hit this, and be surprised or confused.

I am hoping that this post helps with this potential confusion.

Change https://golang.org/cl/168558 mentions this issue: image/png: add Fuzz function

@katiehockman @thepudds What is the status of this issue considering the active work on fuzzing? Thanks.