Open dominikh opened 4 months ago
This seems to me a cmd/cgo
issue, not the runtime.
cgo does not recorgnize that up(&x.self)
is a type conversion, so it emits the cgo check pointer call with up(&x.self)
as argument, not &x.self
in case of unsafe.Pointer(&x.self)
.
I don't know how to fix this except to do full type checking on the cgo input file, which is difficult as we currently expect the type checker to run on cgo output, not cgo input. Fixing this correctly may require something like #16623, which is a lot of work.
@ianlancetaylor We could probably record type alias only, something like map[string]string{"up": "unsafe.Pointer"}
, then the p.isType
check can correctly recognize and stripe the type conversion.
We can handle simple cases, but what if we import some other package that has type MyUnsafePointer = unsafe.Pointer
and then refer to it as otherpkg.MyUnsafePointer(x)
? Is it better to have some type aliases work and some not, or is it better to not try to make type aliases work? It's not clear to me which approach is less confusing.
A related previous issue was https://github.com/golang/go/issues/57926, in which users exploited the desugaring of cgo to declare methods on types that appear to belong to package C: func (C.T) method() {}
The resolution was to use syntactic heuristics to try to reject it, so that we at least make clear that this is not allowed, even if we can't detect it in general (e.g. in the presence of aliasing) without type checking, which is infeasible for the reason @ianlancetaylor noted.
@ianlancetaylor Assigned it to you for now, please feel free to update.
Thanks, I'm unassigning as I have no plans to work on this.
Go version
go version devel go1.23-07fc59199b Sun May 12 05:36:29 2024 +0000 linux/amd64
Output of
go env
in your module/workspace:What did you do?
Run the following code:
What did you see happen?
The first and third calls panic with
runtime error: cgo argument has Go pointer to unpinned Go pointer
. The second call doesn't panic.What did you expect to see?
Only the first call to panic.
Arguably one might also expect all 3 calls to panic, since this also panics, regardless of the use of an alias:
Which makes the use of the 2nd form rather brittle.