go-fuzz icon indicating copy to clipboard operation
go-fuzz copied to clipboard

'go generate' in ./go-fuzz requires installing go-bindata

Open thepudds opened this issue 4 years ago • 4 comments

There is a decent chance I am just confused here, but as far as I can tell, I suspect if your starting point is a clean environment, then running go generate in the go-fuzz/go-fuzz directory requires first installing some flavor of go-bindata.

If you don't, you get an (unhelpful?) error:

Cannot find go-bindata executable in path"
Maybe you need: go get github.com/elazarl/go-bindata-assetfs/..."

(I suspect the advice emitted on the second line there by elazarl/go-bindata-assetfs is incorrect based on briefly looking at that repo, as well as based on trying that suggested step and then seeing it not help ;-)

elazarl/go-bindata-assetfs is vendored by go-fuzz, but I suspect it alone is not complete.

The corresponding go generate commands are: https://github.com/dvyukov/go-fuzz/blob/1810d380ab9c2786af00db592f86d83063216ed0/go-fuzz/main.go#L23-L26

I tried a couple different flavors of go-bindata.

Based on comparing the output results, I suspect the most recent go generate run by @josharian in https://github.com/dvyukov/go-fuzz/commit/1e7aea50942f7d9c5c9ecfbb2e2826e92bd0a417 was using https://github.com/kevinburke/go-bindata, but not 100% sure. (The older https://github.com/jteeuwen/go-bindata seems pretty clearly not to be the flavor that was used).

If you are starting in a clean environment with a copy of dvyukov/go-fuzz, then this seems to work for me:

go get -u github.com/kevinburke/go-bindata/...
go get -u golang.org/x/tools/cmd/goimports
go get -u golang.org/x/tools/cmd/stringer
cd dvyukov/go-fuzz/go-fuzz
go generate

Part of the context here is that at the time I was looking into what it would take to embed the support packages into the binaries (#252).

I haven't dived very deeply here, so sorry in advance if this is incorrect.

thepudds avatar Oct 13 '19 14:10 thepudds

It seems entirely plausible that I used https://github.com/kevinburke/go-bindata by mistake. I had been experimenting with various forks and ideas around that time. (One idea was to use DATA asm instructions for zero-cost readonly []byte embedded data.)

I don’t feel strongly at all about which bindata generator we use. Most are geared towards net/http etc and are serious overkill for go-fuzz, which only needs a few constant strings.

Actually, I wonder whether using txtar would be better. Then there’s no generate step at all—you just edit and use.

Anyway, feel free to make an executive decision, document it / use it as appropriate, and forge ahead.

josharian avatar Oct 13 '19 18:10 josharian

I wonder whether using txtar would be better.

Or even just a few plain ol' Go const strings. There aren't many of these files, they're short, etc.

josharian avatar Oct 16 '19 01:10 josharian

So, Go 1.16 is released. You can use now //go:embed.

tdakkota avatar Feb 20 '21 16:02 tdakkota

Good point. But since go-fuzz will soon be replaced by the standard library, I’m inclined not to change things—and require 1.16—at this point.

josharian avatar Feb 20 '21 19:02 josharian