Re: [go-nuts] Re: Possible Go Compiler or Runtime bug?

On Thu, Jul 27, 2023 at 3:17 PM 'Michael Knyszek' via golang-nuts wrote: > > The number 32 for the capacity comes from this constant, and the returned > byte slice in that case is likely coming from a compiler-inserted call to > stringtoslicebyte. An empty string is correctly replaced by a

[go-nuts] Re: Possible Go Compiler or Runtime bug?

On Thursday, July 27, 2023 at 6:16:57 PM UTC-4 Michael Knyszek wrote: I believe this is working as intended, because I don't think the spec makes any guarantees about the capacity of the slice you get back from a conversion. (Other than the fact that the

[go-nuts] Re: Possible Go Compiler or Runtime bug?

The number 32 for the capacity comes from this constant , and the returned byte slice in that case is likely coming from a compiler-inserted call to stringtoslicebyte

[go-nuts] Re: Possible Go Compiler or Runtime bug?

Interesting: https://play.golang.com/p/nSZ7tKSeot4 With the Printf commented out, it shows t has a cap of 32. With Printf uncommented, the cap drops to 0. Maybe the slice buffer is allocated on the stack in one case, and the heap on another? The slice header of 24 bytes shouldn't have

[go-nuts] Re: Possible Go Compiler or Runtime bug?

That looks very weird. The panic is triggered if I uncomment line 17 (the final fmt.Printf) even though it never reaches there - it panics when getStrBytes is called from line 9 (in line 23). On Thursday, 27 July 2023 at 13:12:40 UTC+1 Kyle Harrity wrote: > I first asked this on