/cc @alexbrainman @bradfitz per owners.

These are false positives.
(There is a reason this is not one of the vet checks that runs automatically during go test.)
The one in env_windows.go could be rewritten to avoid the check but is still OK as is.
The ones in zsyscall_windows.go cannot be rewritten.

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:

Vet uses heuristics that do not guarantee all reports are genuine problems, but it can find errors not caught by the compilers.

Most of vet's checks are heuristic and can generate both false positives (flagging
correct programs) and false negatives (not flagging incorrect ones). The rate of
both these failures must be very small.

This means you cannot rely on default behavior of go vet in CI, where a false positive (that isn't a bug) is generally not acceptable.

@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?

Note that the current very-high-confidence vet checks are already enabled during go test.
In the long term we are working toward enabling all of them, once they are high enough confidence.
This one in particular we may adjust or may just never enable.
But for CI purposes, I would suggest that you rely on "go test".

One plausible way to address this is to add support to suppress false positives in vet at specific locations/functions. staticcheck supports this via //lint:ignore https://staticcheck.io/docs/#line-based-linter-directives (as do quite a few linters for other languages). OTOH this feature may result in worse code if folks suppress true positives.

But for CI purposes, I would suggest that you rely on "go test".

I am not sure we will want steer folks away from go vet in CI. But I also think anyone willing to run vet in CI needs to tolerate some FPs. Providing a mechanism for validating the FPs you are okay with/expect might be a nice feature.

It turns out to be possible to suppress all of these warnings in x/sys, I think. See https://go.dev/cl/465235.

Change https://go.dev/cl/465235 mentions this issue: all: silence unsafeptr vet checks

Change https://go.dev/cl/465596 mentions this issue: internal/vettest: test that all packages in x/sys are free of vet warnings

Change https://go.dev/cl/465597 mentions this issue: unix: add missing address operator in initxattrdest

Change https://go.dev/cl/465676 mentions this issue: unix: mitigate uintptr violations in PtraceIO on freebsd

Meanwhile the Go Team do not fix this issue, you can disable the warning by editing the settings.json in vscode.

{
   "go.useLanguageServer": true, // if this is true, needs gopls/analyses flag.
    "go.vetFlags": [
        "-unsafeptr=false"
    ],
    "gopls": {
        "analyses": { "unsafeptr": false }
    }
}

Change https://go.dev/cl/492415 mentions this issue: windows: use unsafe.Add instead of pointer arithmetic on a uintptr