Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/vet: printf analyzer cannot analyze anonymous functions #44350

Open
corhere opened this issue Feb 17, 2021 · 1 comment
Open

cmd/vet: printf analyzer cannot analyze anonymous functions #44350

corhere opened this issue Feb 17, 2021 · 1 comment

Comments

@corhere
Copy link

@corhere corhere commented Feb 17, 2021

What version of Go are you using (go version)?

$ go version
go version go1.16 linux/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output
$ docker run --rm golang:1.16 go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.16"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build813662227=/tmp/go-build -gno-record-gcc-switches"
GOROOT/bin/go version: go version go1.16 linux/amd64
GOROOT/bin/go tool compile -V: compile version go1.16
uname -sr: Linux 4.19.121-linuxkit
/lib/x86_64-linux-gnu/libc.so.6: GNU C Library (Debian GLIBC 2.28-10) stable release version 2.28.

What did you do?

Ran go vet on a package containing the following:

package vetexample

import "fmt"

func BuggyCode() error {
	failf := func(format string, args ...interface{}) error {
		return fmt.Errorf(format, args)
	}
	return failf("%v")
}

What did you expect to see?

go vet catches the mismatch between the format string and argument list in the failf call.

What did you see instead?

The package passed vetting.


This pattern of wrapping a printf-family function in a closure can also be found in the Go sources.

invalidf := func(format string, args ...interface{}) error {
return &module.ModuleError{
Path: r.modPath,
Err: &module.InvalidVersionError{
Version: info2.Version,
Err: fmt.Errorf(format, args...),
},
}
}

While I would not expect go vet to be able to analyze in general whether a function value wraps (or is) a printf-family function, might it be viable to analyze the more limited case of a function-scoped local variable which is assigned a function literal value?

@zpavlinovic
Copy link

@zpavlinovic zpavlinovic commented Feb 19, 2021

go vet has the ability to identify failf as a printf wrapper. The reason it does not identify it, to my understanding, is because failf is not a top-level function. That is, failf is not considered a printf wrapper as it is a variable whose contents can change.

go vet could be extended to cover locally defined functions such as failf and then check for input formatting issues iff such failfs are, for instance, only being called in the enclosing function and nothing else (e.g., passed as a parameter or assigned a value).

The question is, how prevalent is the code pattern just described? Could we somehow get data on that to justify the above described extension?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants