Unexpected Pointer Behavior in range Loop Over Maps in Go (Go 1.24.1)

[wolfhermann]

Go version

1.24.1

Output of go env in your module/workspace:

AR='ar'
CC='gcc'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='g++'
GCCGO='gccgo'
GO111MODULE=''
GOAMD64='v1'
GOARCH='amd64'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/home/sa/.cache/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/home/sa/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build2569810058=/tmp/go-build -gno-record-gcc-switches'
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMOD='/home/sa/dev/core/go.mod'
GOMODCACHE='/home/sa/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/sa/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTELEMETRYDIR='/home/sa/.config/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.24.1'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

I'm encountering unexpected behavior when iterating over a map in Go 1.24.1, where pointers to map values inside a range loop do not behave consistently across different environments. The issue manifests as the pointers either referring to the same object (the last item in the loop) or different items, depending on the platform.

Code Example:

package main

import (
	"fmt"
)

type KeyItem struct {
	ID      int
	Version string
}

type Item struct {
	ID    int
	Value string
}

func main() {
	// Define an array of items
	items := map[KeyItem]Item{
		{ID: 1, Version: "1"}: {ID: 1, Value: "Item 1"},
		{ID: 2, Version: "2"}: {ID: 2, Value: "Item 2"},
		{ID: 3, Version: "3"}: {ID: 3, Value: "Item 3"},
	}

	var recordPointer1 *Item
	var recordPointer2 *Item

	// Add only the first item from the loop to the map
	for key, item := range items {
		fmt.Printf("Currently processing: %v\n", item)
		if key.ID == 1 {
			fmt.Printf("Updating pointer 1 to %v\n", item)
			recordPointer1 = &item
		}
		if key.Version == "2" {
			fmt.Printf("Updating pointer 2 to %v\n", item)
			recordPointer2 = &item
		}
	}

	// Check what the map points to after the loop
	fmt.Printf("Pointer1 content after full iteration: %v\n", *recordPointer1)
	fmt.Printf("Pointer2 content after full iteration: %v\n", *recordPointer2)
}

What did you see happen?

• On Go Playground (https://go.dev/play/), the output is:

  Pointer1 content after full iteration: {1 Item 1}
  Pointer2 content after full iteration: {2 Item 2}
  

• On CodeChef Go Online Compiler (https://www.codechef.com/go-online-compiler), the output is:

  Pointer1 content after full iteration: {1 Item 1}
  Pointer2 content after full iteration: {1 Item 1}
  

What did you expect to see?

I know that the Go range loop over maps reuses the same variable for each iteration, which can lead to unexpected behavior when taking pointers to the map values. This happens because the memory for item is reused across iterations, causing all pointers to potentially reference the same underlying object (the last one processed).

The issue can be resolved by explicitly creating a copy of the item inside the loop:

itemCopy := item
recordPointer1 = &itemCopy

Nevertheless I am highly surprised that I see different outcome using different or even the same go version (1.24.1) dependent on the actual environments.

Request for Clarification:

• Is this behavior considered a bug in Go, or is it expected behavior due to how the range loop is designed? Should developers expect this behavior across all Go versions, or is it a side effect of specific compiler or runtime configurations?
• Even if this behavior is by design, is there any intention to make it clearer in the documentation or to change it in the future? This pattern introduces an implicit risk of misuse, as developers might unintentionally rely on incorrect pointer behavior, leading to subtle bugs that are difficult to diagnose.

Thanks for your support!

[seankhliao]

that compiler is using go1.20.6, before the loopvar change https://go.dev/blog/loopvar-preview
(you can check through reading runtime/debug.BuildInfo)

Closing as working as intended

Unlike many projects, the Go project does not use GitHub Issues for general discussion or asking questions. GitHub Issues are used for tracking bugs and proposals only.

For questions please refer to https://github.com/golang/go/wiki/Questions

[gabyhelp]

Related Issues

• For loop with map produces incorrect values when assigned in-loop to new struct #65881 (closed)
• for on a map reuses the same address for values #17303 (closed)
• Incorrect pointers while iteration through list with RANGE keyword #16149 (closed)
• Iterating slice of values and calling their method with pointer receiver behaves inconsistently #28844 (closed)
• spec: clarify range over maps will produce every non-deleted entry avaiable when it starts #35239
• spec: range & go: pass a pointer to an element of array leads to a different behavior with/out go #10132 (closed)
• text/template: key/value assignment is reversed within range loop #60801 (closed)
• Convert slice of type A to slice of pointers to type A #22791 (closed)
• Bug with []byte struct field at append slice in for range loop #35340 (closed)

Related Discussions

• building a map of pointer values with a for loop sets all values to the same pointer

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[zigo101]

see https://go101.org/blog/2024-03-01-for-loop-semantic-changes-in-go-1.22.html