x/tools/go/passes/unsafeptr: detect "liveness holes"

[adonovan]

The code below forms a new pointer y by adding an offset to another pointer ptr:

y := uintptr(unsafe.Pointer(ptr)) + uintptr(n)
return (*byte)(unsafe.Pointer(y))

If ptr is the sole reference to a variable, then after the assignment to y is complete, there are no more references to that variable and the GC is free to reclaim its storage. By the time the new pointer is formed in the return statement, the variable may no longer exist.

The correct code either inlines the expression for y into the return statement, or moves the unsafe.Pointer(y) conversion into the definition of y, so that after every statement, the variable is live.

Although the existing unsafeptr package detects some pointer mistakes, it does not detect this one. It should.

See also:

• x/tools/go/analysis/passes/modernize: replace unsafe pointer arithmetic with unsafe.Add(ptr, n) #76648

[dominikh]

Is the unsafeptr pass different from whatever go vet uses to flag your example?

$ cat bar.go
package pkg

import "unsafe"

func foo(ptr *int, n int) *byte {
	y := uintptr(unsafe.Pointer(ptr)) + uintptr(n)
	return (*byte)(unsafe.Pointer(y))
}

$ go vet bar.go
bar.go:7:17: possible misuse of unsafe.Pointer

[adonovan]

Well that's odd: I was using gopls, which includes unsafeptr in its analyzer suite, and it didn't show any diagnostics. But you're right, go vet reports a diagnostic, and so too does gopls check bar.go. After M-x eglot the diagnostic appears. I think eglot has gotten itself into a bad state---and I'm pretty sure I have encountered this before. Will report a bug when I can spot the pattern. Thanks for the correction.