On Fri, Nov 25, 2022 at 12:45 PM Frédéric De Jaeger
<
fdej...@novaquark.com> wrote:
>
> I was not asking for a conversion of a uintptr to an arbitrary pointer, that would way too unsafe; but a conversion of uintptr to an arbitrary C pointer (the same kind of typing rule that currently exists to allow casts back and forth between uintptr and unsafe.Pointer). It would have the obvious semantic, with no interference with the runtime.
>
> Seeing other issues like
https://groups.google.com/g/golang-nuts/c/wcG1vKnDVkc, that would help in many places. There is no compatibility issue. I don't think it makes cgo any more dangerous to use. For that to be fully useful, the compiler would have to accept the type *C.void in a cast expression.
>
> Alternatively, you could provide a type `cgo.Pointer`, that has the same typing rule as unsafe.Pointer, but has no pointer semantic. But that would be too confusing, I don't like it.
The Go language and Go compiler don't have a notion of a C pointer.
They just know about pointers and other types. If p has type *C.char,
then Go code is permitted to write *p to get a value of type C.char.
That is, a value of type *C.whatever is just a pointer like any other
pointer type. The only thing that is unusual about it is that
C.whatever is defined by C code. And that definition is handled
entirely by the cgo tool. It's not part of the Go language and the Go
compiler doesn't know anything about it.
> Then I think that might be good to document in cgo, close to this sentence: "The C type void* is represented by Go's unsafe.Pointer."
> that it is illegal to put an invalid pointer in an unsafe.Pointer.
Well, maybe. We can't document everything everywhere. The
restriction is not specific to unsafe.Pointer, you can't put an
invalid pointer in any pointer type. There is a separate section in
the cgo docs about passing pointers.
Ian