thepudds

I have a modest counter proposal, including a couple of quick comments on some of the recent bugs reported against go-fuzz, but I won’t be able to circle back here...

Hi all, some quick comments. Josh's proposal will very likely be the ultimate outcome here, and that has been the [goal](https://docs.google.com/document/u/1/d/1zXR-TFL3BfnceEAWytV8bnzB2Tfp6EPFinWVJ5V4QC8/pub)... However, I'd like to suggest "maybe not quite yet"....

Hi @dvyukov, just wanted to check in on this. Josh gave it a +1 above, and the original reporter confirmed it fixed it for them, as well as @klauspost above....

Hi @raminfp I don’t know whether or not gccgo is expected to work with go-fuzz. Do things work for you if you use the standard go tool chain (e.g., https://go.dev/doc/install)?

Hi @hidu and @howardjohn It sounds like the desire was to use something like the `go1.16.3` binary installed via golang.org/dl/go1.16.3. How are you doing that today? I think it might...

I think it might be https://github.com/golang/go/issues/49598, but I need to confirm.

To possibly help narrow the problem, can you try with Go 1.15?

A good next step likely is going back to Go 1.16 and do `go-fuzz-build -x -work`, which will print more details about the commands issued, as well as leave behind...

I suspect that the `ast.CallExp` construction there is incorrectly handling the type alias in Go 1.16: https://golang.org/src/os/types.go?s=798:825#L18 `type FileMode = fs.FileMode`

Hi all, I'm curious if anyone else encountering this issue was able to successfully use the workaround that @disconnect3d suggested immediately above, or on the other hand, if anyone tried...