[go-nuts] cgo: Special case in unpinned go pointer checks

Dear golang nuts, I was trying to gain a better understanding of how cgo works internally, when I stumbled upon this implementation detail: https://github.com/golang/go/blob/8db131082d08e497fd8e9383d0ff7715e1bef478/src/runtime/cgocall.go#L628 ``` case kindStruct: st :=

Re: [go-nuts] Is it safe to keep noCopy types in a slice which might copy on re-alloc?

On Sunday, August 27, 2023 at 7:05:15 PM UTC+2 Ian Lance Taylor wrote: > On Sun, Aug 27, 2023 at 7:54 AM Antonio Caceres Cabrera > wrote: > > > > Go vet complains about this minimal example code > > > > type Foo struct { > > val atomic.Uint64 > > } > > &

[go-nuts] Is it safe to keep noCopy types in a slice which might copy on re-alloc?

Go vet complains about this minimal example code type Foo struct { val atomic.Uint64 } func main() { var foos = make([]Foo, 0) var bar Foo bar.val.Store(5) foos = append(foos, bar) // call of append copies lock value: example.com/foo.Foo contains

[go-nuts] Is atomic.CompareAndSwap a read-aquire (even if it returns false)?

Hi Gophers, I have a question about a more subtle part of the language, the memory model regarding atomic operations. The memory model doc on go.dev states: >If the effect of an atomic operation *A* is observed by atomic operation *B*, then *A* is synchronized before *B*.[...] I.e. "observing