Go has a non-moving GC [1], so that is not an issue. That said, unsafe.Pointer states "the referenced allocated object, if any, is retained and not moved until the call completes". It doesn't say that this recursively applies to objects referenced by the converted object, though I perhaps it should.
[1] Except for stacks, but taking the address of a byte slice and putting it in Iovec.Base will force it to escape anyways. On Fri, May 14, 2021 at 9:44 AM Shaun Crampton <sh...@tigera.io> wrote: > > You can use a *byte for the buffer. For instance, unix.Iovec does this > > Are you sure that's not a bug? What's to stop the *Byte from being > moved by the GC? > > On Fri, May 14, 2021 at 2:27 PM Michael Pratt <mpr...@google.com> wrote: > > > > You can use a *byte for the buffer. For instance, unix.Iovec does this: > https://pkg.go.dev/golang.org/x/sys/unix#Iovec > > > > Users can cast a *unix.Iovec directly to unsafe.Pointer for Syscall > without any special handling of the *byte field. > > > > On Fri, May 14, 2021, 09:01 sh...@tigera.io <sh...@tigera.io> wrote: > >> > >> Now, is it technically legal to convert a uintptr to some location that > was manually allocated and then cast it to an unsafe.Pointer? When I look > at the docs for unsafe.Pointer, I can't match that to any of the cases but > it seems very likely to be safe by analogy with the GCO rules for handling > "C" pointers and "Go" pointers. > >> > >> On Friday, May 14, 2021 at 1:24:28 PM UTC+1 sh...@tigera.io wrote: > >>> > >>> Thanks for the pointer to that package; looking at our go.mod, looks > like we've already got it as a transitive dependency so it looks ideal for > my use case. > >>> > >>> On Friday, May 14, 2021 at 12:10:45 PM UTC+1 Jan Mercl wrote: > >>>> > >>>> On Fri, May 14, 2021 at 12:36 PM sh...@tigera.io <sh...@tigera.io> > wrote: > >>>> > >>>> > One way I could see to solve this would be to do some manual memory > management with MMap or BRK to allocate the buffer but I wondered if there > was an easier way? > >>>> > >>>> IMO using manual memory management _is_ the easy way in this case. I'm > >>>> using https://pkg.go.dev/modernc.org/memory for this. > >> > >> -- > >> 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/317d44cf-8f2b-42d6-ab10-b42da7280616n%40googlegroups.com > . > -- 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/CALoThU8Qe8p1XyycwcoHnAcXG46DXYKWvDhLSUakAKN7fYmwHA%40mail.gmail.com.
