-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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: "possible misuse of unsafe.Pointer" check false positive rate may be too high #41205
Comments
/cc @alexbrainman @bradfitz per owners. |
These are false positives. I don't believe there's anything to do here. |
go-vet's false positive happens not only on x/sys/windows but also on my library using Syscall. IIUC, as Syscall returns uintptr, it is impossible to use them as a pointer without violating the unsafe.Pointer rule (is that correct?). Now I cannot run go-vet for my library on Windows CI due to this issue. I'd be happy if go-vet could avoid such false positives. |
The check is "possible misuse of unsafe.Pointer", not "misuse of unsafe.Pointer". Based on Russ's comment, I understand there is no actual misuse of unsafe.Pointer in the golang.org/x/sys/windows package. I'll retitle this to be about cmd/vet then, but I agree this may be working as intended. The presence of a "possible ..." check in vet is incompatible with running in CI systems such that any trigger fails the build. |
vet's documentation and README suggest that false positives are allowed by design:
This means you cannot rely on default behavior of @hajimehoshi Do you think there's an issue, or do you agree this is working as intended? |
I think there's still an issue. As we have already known these (uintptr usages of Syscall) are detected as false positives, the unsafe.Pointer rule and go-vet should be updated. Based on the vet's documentation, the rate of false positive (and negative) must be very small, right? |
This comment has been minimized.
This comment has been minimized.
Note that the current very-high-confidence vet checks are already enabled during go test. |
One plausible way to address this is to add support to suppress false positives in
I am not sure we will want steer folks away from |
Update actions to v3. Go vet is commented out due to false positives in golang/go#41205. PiperOrigin-RevId: 492508300
Update actions to v3. Go vet is commented out due to false positives in golang/go#41205. PiperOrigin-RevId: 492508300
Update actions to v3. Go vet is commented out due to false positives in golang/go#41205. PiperOrigin-RevId: 492508300
Update actions to v3. Go vet is commented out due to false positives in golang/go#41205. PiperOrigin-RevId: 493685245
It turns out to be possible to suppress all of these warnings in |
Change https://go.dev/cl/465235 mentions this issue: |
Change https://go.dev/cl/465596 mentions this issue: |
Change https://go.dev/cl/465597 mentions this issue: |
Change https://go.dev/cl/465676 mentions this issue: |
The purpose of the _zero variable is to provide a valid address for a pointer to an array of length zero. All other uses of the variable take its address, but one reference to it (added in CL 147850043) converts the variable (which has type uintptr) directly to an unsafe.Pointer, producing a nil pointer instead of a non-nil pointer to a zero-length array. This typo is caught by 'go vet', but was masked for a long time by the numerous false-positive warnings for the same check (#41205). For golang/go#41205. Change-Id: Ib3bebfadc6fc5574db19630169ff3f65da857bdd Reviewed-on: https://go-review.googlesource.com/c/sys/+/465597 Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com> Auto-Submit: Bryan Mills <bcmills@google.com>
In CL 419915, both pointer fields of the PtraceIoDesc struct were converted to type uintptr to address golang/go#54113. However, that change was overzealous: the fix needed to convert fields that refer to addresses in the child process, but the Addr field of PtraceIoDesc is not even in the child process! It is instead an address in the parent (Go) process. Go's unsafe.Pointer rules prohibit converting a Go pointer to a uintptr except when immediately converting back to an unsafe.Pointer or calling a system call. Populating a PtraceIoDesc struct is neither of those things, so converting the Addr field to uintptr introduced a use-after-free bug. This change reverts the change to the Addr field from CL 419915 and consolidates the implementation of PtraceIO to reduce the the amount of code that varies with GOARCH. This change does not address the remaining ptrace uintptr bug (golang/go#58387), which is also present in the Linux implementation. Fixes golang/go#58351. Updates golang/go#54113. For golang/go#41205. Change-Id: I14bdb4af42130aa7b4375e3f53fd1a0435f14307 Reviewed-on: https://go-review.googlesource.com/c/sys/+/465676 Auto-Submit: Bryan Mills <bcmills@google.com> Run-TryBot: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
Meanwhile the Go Team do not fix this issue, you can disable the warning by editing the settings.json in vscode.
|
Change https://go.dev/cl/492415 mentions this issue: |
The existing uintptr arithmetic is arguably valid because the environment block is not located within the Go heap (see golang/go#58625). However, unsafe.Add (added in Go 1.17) expresses the same logic with fewer conversions, and in addition avoids triggering the unsafeptr vet check. For golang/go#41205. Change-Id: Ifc509279a13fd707be570908ec779d8518b4f75b Reviewed-on: https://go-review.googlesource.com/c/sys/+/492415 Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Bryan Mills <bcmills@google.com>
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
What did you expect to see?
No warnings
What did you see instead?
The text was updated successfully, but these errors were encountered: