x/tools/go/analysis/passes/printf: false positive breaks tests in package

[mark-pictor-csec]

Go version

go1.23, go1.22, tip

Output of go env in your module/workspace:

N/A (repro in playground)

What did you do?

I wrote a function which takes optional args of type any; if the first optional arg is of type string, it is passed to fmt.Sprintf as the format.

The vet check believes I'm incorrectly providing a format specifier; until I found a way to defeat the check, it prevented any tests within the package from running.

https://go.dev/play/p/b6AupyJEr6s

printf analyzer documentation is available on pkg.go.dev

What did you see happen?

The printf checker produces a false positive, and there doesn't seem to be a way to disable it. I was unable to run any tests in the affected package until I found a way to defeat the checker.

What did you expect to see?

go test and the playground compile and execute the code.

[gabyhelp]

Related Issues and Documentation

• x/tools/go/analysis/passes/printf: suggest Printf calls without args to use Print #69515
• cmd/vet: printf analyzer cannot analyze anonymous functions #44350
• x/tools/analysis/passes/printf: regression in format type checks #28858 (closed)
• cmd/vet: false positive in Printf recursive Stringer check with non-matching String() functions #30441 (closed)
• cmd/vet,x/tools/go/analysis/passes/printf: broken with GODEBUG=gotypesalias=1 #68796 (closed)
• cmd/vet: failed import causes spurious printf error #17006 (closed)
• cmd/vet: false positive about wrong number of arguments in printf #23564 (closed)
• cmd/vet: don't suggest ... if it breaks a program
• x/tools/go/analysis/passes/printf: say what the right type is in the analyzer #59875 (closed)
• cmd/vet: false positives and wrong types across files, needs automatic recursive checking #20514 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[timothy-king]

cc @adonovan

[adonovan]

The printf checker produces a false positive, and there doesn't seem to be a way to disable it. I was unable to run any tests in the affected package until I found a way to defeat the checker.

I appreciate that this change was quite inconvenient for you, but I will note that it is very confusing to declare a function that behaves like either Printf or Print depending on whether the first argument is a string--not only for static analysis tools like vet but for human readers too. I suggest you use this opportunity to rewrite the function to always behave like Sprintf, and give its name an f suffix.

[mark-pictor-csec]

Commenting out lines 32 and 33 does cause the check to pass, which I was not at all expecting. Thanks for the hint!

[mark-pictor-csec]

This seems like something that's pretty unlikely to be hit, and difficult to fix. Feel free to close it if you want.

[adonovan]

To be clear, commenting out L32-33 doesn't really improve the function, as it still exhibits "conditionally printf-like" behavior. It would better if it was either always print-like or always printf-like, as these are well understood paradigms for most Go programmers, and the vet tool will enforce the correct discipline. For example:

// printf-like:

func PrintfIdx(s string, n int, format string, args ...any) {
	if len(s) == 0 {
		return
	}
	x := fmt.Sprintf(format, args...)
	fmt.Fprintf(os.Stderr, "\n%q  %s\n %*s  (%d)\n", s, x, n+1, "^", n)
}

PrintfIdx("", 0, "%s", 123) // <-- vet will point out the mismatch between %s and 123


// print-like:

func PrintIdx(s string, n int, args ...any) {
	if len(s) == 0 {
		return
	}
	x := fmt.Sprint(args...)
	fmt.Fprintf(os.Stderr, "\n%q  %s\n %*s  (%d)\n", s, x, n+1, "^", n)
}

PrintIdx("", 0, "%s", 123) // <-- vet will point out that the first argument looks like an unwanted format string.

[adonovan]

Working as intended; closing.