Sorry, accidentally hit the wrong response button, so I'm posting it again:
Thanks for the clarification, Ian.
Is it also possible to pin memory to local go-arrays?
The docs state
>Go values created by calling new, by taking the address of a composite
literal, or by taking the address of a local variable may also have their
memory pinned using runtime.Pinner.
In this example:
```
var pin runtime.Pinner
var buf [32]byte
pin.Pin(&buf[0])
C.keep_this_pointer(&buf[0])
```
Is this ok since it counts as taking the address of a local variable or
would the array have to be created with `new([32]byte)` ?
Julio
On Sunday, July 7, 2024 at 5:38:13 PM UTC+2 Ian Lance Taylor wrote:
> On Sun, Jul 7, 2024 at 6:17 AM Antonio Caceres Cabrera
> <julioca...@gmail.com> wrote:
> >
> > I'm trying to use cgo for a C library, specifically a function which
> takes a void pointer to a buffer, and I'm trying to pass a Go-Slice as this
> buffer.
> >
> > ```
> > func Write(buf []byte) (int, error) {
> > // var pin rumtime.Pinner
> > // pin.Pin(&buf[0])
> > // defer pin.Unpin()
> > // is this necessary? Is it even safe?
> > ...
> > ret := C.lib_read(unsafe.Pointer(&buf[0]), C.int(len(buf))) // function
> which reads from this buffer
> > ...
> > }
> > ```
> > Does this require explicit pinning of buf? And if so, is the commented
> part a valid pinning of a slice? The documentation states that pointers
> passed to C functions are implicitly pinned (on the top-level that is), but
> does this also apply to slices, i.e. if I pass a (unsafe) pointer to the
> first element, is the slice's entire backing array implicitly pinned?
> >
> > I know that there are some runtime checks for this, but I am worried
> that any use of unsafe.Pointer might perhaps override these checks
> completely.
>
> This kind of code does not require explicit pinning. As you note,
> passing a pointer to C implicitly pins the memory that the pointer
> points to. Further, the cgo docs say "When passing a pointer to an
> element in an array or slice, the Go memory in question is the entire
> array or the entire backing array of the slice." In other words, yes,
> the slice's entire backing array is implicitly pinned. The cgo tool
> is smart enough to ignore type conversions when deciding what memory
> needs to be pinned.
>
> Ian
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/6d7799a5-4fd3-4025-b76d-d3dcb9d44090n%40googlegroups.com.
