It seems the issue has to do with the compiler inlining `foo`. If I add the
compiler directive `//go:noinline` above `foo` and run `go test` the test
fails, just like when I run `go test -covermode=atomic`. This makes sense
because if the function is inlined and the slice is allocated on the sta
Interesting, I actually ran into some odd behavior with this function that
I'm not sure how to explain. Consider the following test:
import (
"reflect"
"testing"
"unsafe"
)
func sliceToStringUnsafe(v []byte) string {
var s string
sh := (*reflect.StringHeader)(unsafe.Pointer(&s))
sh.D
That is a worry, but escape analysis can handle this case. It understands
flow of pointers through unsafe.Pointer and uintptr. As a consequence, in
this example it forces the array to be allocated on the heap.
The runtime has on occasion a need to hide values from escape analysis. It
has to
It just occurred to me that there may actually be a problem with the
conversion functions in the example. Specifically, since the Go
compiler can allocate byte slices on the heap if they do not escape, the
following function may be invalid:
func foo() string {
v := []uint64{1,2,3}
Filed: https://github.com/golang/go/issues/19687
On Thu, Mar 23, 2017 at 4:41 PM, 'Keith Randall' via golang-nuts
wrote:
>
>
> On Thursday, March 23, 2017 at 4:24:40 PM UTC-7, Caleb Spare wrote:
>>
>> That's very good to know. Thanks, Ian.
>>
>> Unfortunately if I use this KeepAlive-based fix, p
That only applies to []byte. I have a []uint64.
On Feb 23, 2017 4:13 AM, "T L" wrote:
>
>
> On Wednesday, February 22, 2017 at 6:53:53 AM UTC+8, Caleb Spare wrote:
>>
>> I have a program that uses unsafe in order to coerce some slices to
>> strings for use as map keys. (Avoiding these allocation
