On Friday, July 28, 2023 at 6:44:21 AM UTC+8 wagner riffel wrote:
On 27/07/2023 03:48, Kyle Harrity wrote: > Maybe this is a known issue and or expected behavior so I thought I'd > ask here before raising an issue on github. > I think I know what's going on, the compiler inlined getStrBytes and can prove "k" is short enough to put in the stack, then the runtime creates the slice backed from an array on the stack, but never sets its capacity, just length, so you're left with 32 bytes of capacity to expand (see https://go.googlesource.com/go/+/refs/tags/go1.20.6/src/runtime/string.go#170). When you uncomment your print of k, then the compiler can't prove that fmt.Printf won't keep the address of k, so it's not safe to store it on the stack anymore, and you have the "expected behavior", an array allocated from rawbyteslice which does set the capacity to len(s) (0 in this case). Note that even if it is not stored on the stack, the behavior is still not always "expected". When it is stored on heap. the capacity will be aligned to a nearby memory class size (even this is also implementation specific). In the linked code above, changing "b = buf[:len(s):len(s)]" should "fix" this, it's quoted because I did grasp through the spec and couldn't find anything about which is the capacity of a slice created from a conversion of a string, as far as I can tell both programs are valid. -- 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/bcb56d33-f24f-4baa-87da-db156d10ab67n%40googlegroups.com.
