opened
eliasnaur
username_0
The Windows HANDLE type is translated to an unsafe.Pointer in by cgo, but can contain non-pointer values; it should be treated accordingly. Incomplete pointer types such as the [JNI types](https://github.com/golang/go/issues/40954#issuecomment-678391202) are covered by a rule so that they're not treated as pointers. However, that rule does not match HANDLE, which is a `void *`.

From [golang-dev](https://groups.google.com/g/golang-dev/c/-sAWsdTv9JU/m/ENQucQr5CwA):
```
package main

import (
    "fmt"
    "os"
    "path/filepath"
    "runtime"

    "golang.org/x/sys/windows"
)

/*
#include <windows.h>
*/
import "C"

func main() {
    name := filepath.Join(os.TempDir(), "handletest.tmp")
    name16, err := windows.UTF16PtrFromString(name)
    if err != nil {
        panic(err)
    }
    fmt.Println("Using filepath", name)

    handle := C.CreateFileW((*C.wchar_t)(name16), C.GENERIC_READ, C.FILE_SHARE_READ|C.FILE_SHARE_WRITE, nil, C.CREATE_ALWAYS, 0, nil)
    if handle == C.HANDLE(C.INVALID_HANDLE_VALUE) {
        panic("failed to open")
    }

    fmt.Println("handle addr", handle)

    runtime.GC()

    rtn := C.CloseHandle(handle)
    if rtn == C.FALSE {
        panic("failed to close handle")
    }
}
```

```
go build && handletest.exe
Using filepath C:\Users\Alex\AppData\Local\Temp\handletest.tmp
handle addr 0x154
runtime: bad pointer in frame main.main at 0xc000075f10: 0x154
fatal error: invalid pointer found on stack
```

Duplicate of https://github.com/golang/go/issues/8921.

CC @randall77
runtime/cgo: treat Windows HANDLE as non-pointer type
issue
created
zx2c4
username_1
Cc @username_2
comment
created
eliasnaur
username_0
Gentle ping. Expanding use of Cgo in Gio on Windows is blocked by this issue that is subtle and has no workaround.
comment
created
zx2c4
username_1
Im curious: why not use the faster x/sys/windows syscall trampolines instead of cgo?
comment
created
alexbrainman
username_2
I agree this is a duplicate of #8921. So you have to take it up with @rsc, because he made `working as intended` decision in #8921.

I also agree with @username_1 that you don't need to use Cgo to call Windows APIs.

Alex
comment
created
zx2c4
username_1
We could treat HANDLE as uintptr as a special case, though, I guess?
comment
created
alexbrainman
username_2
I read this as he does not want any exceptions in Cgo.

Alex
comment
created
eliasnaur
username_0
His comment is from 2014, 3 years before adding special cases for [CoreFoundation](https://go-review.googlesource.com/c/go/+/66332/) and [Android JNI types](https://go-review.googlesource.com/c/go/+/81876/). We don't even have to change the mapped type from unsafe.Pointer to uintptr [anymore](https://go-review.googlesource.com/c/go/+/250940).
comment
created
alexbrainman
username_2
I am not familiar with compiler code. If you know what to change, just send CL to Russ or Keith or any compiler developer.

Alex
comment
created
eliasnaur
username_0
I don't know what to change. My comment was to point out that while the older special cases (CoreFoundation, JNI) were breaking changing (Cgo generated type changed from unsafe.Pointer to uintptr), new special cases preserve the type but treat their values as non-pointers.
comment
created
alexbrainman
username_2
I definitely cannot help you with that.

Alex
comment
created
ianlancetaylor
username_3
As far as I know the approach here would be to change cmd/cgo/gcc.go so that when it sees the type `HANDLE` with `GOOS == "windows"` it treats it as a pointer to an empty struct type for which `NotInHeap` is `true`.
comment