go-fuzz
go-fuzz copied to clipboard
'go generate' in ./go-fuzz requires installing go-bindata
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.
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.
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.
So, Go 1.16 is released. You can use now //go:embed
.
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.