cmd/compile: len(*f()) does not panic when f() returns (*[k]T)(nil)

[aykevl]

Go version

go version go1.24.0 linux/arm64

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=''
GOARCH='arm64'
GOARM64='v8.0'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/home/ayke/.cache/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/home/ayke/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build3048126655=/tmp/go-build -gno-record-gcc-switches'
GOHOSTARCH='arm64'
GOHOSTOS='linux'
GOINSECURE=''
GOMOD='/home/ayke/src/tinygo/tinygo/go.mod'
GOMODCACHE='/home/ayke/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/ayke'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go1.24.0'
GOSUMDB='sum.golang.org'
GOTELEMETRY='on'
GOTELEMETRYDIR='/home/ayke/.config/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go1.24.0/pkg/tool/linux_arm64'
GOVCS=''
GOVERSION='go1.24.0'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

I have the following file, called repro.go:

package main

func nilPtrToArray() *[2]byte {
        return nil
}

func foo() {
        println(len(*nilPtrToArray()))
}

func bar() {
        ptr := nilPtrToArray()
        println(len(*ptr))
}

I ran ssadump on it:

# Name: command-line-arguments.init
# Package: command-line-arguments
# Synthetic: package initializer
func init():
0:                                                                entry P:0 S:0
        return

# Name: command-line-arguments.nilPtrToArray
# Package: command-line-arguments
# Location: /home/ayke/src/tinygo/tinygo/repro.go:3:6
func nilPtrToArray() *[2]byte:
0:                                                                entry P:0 S:0
        return nil:*[2]byte

# Name: command-line-arguments.foo
# Package: command-line-arguments
# Location: /home/ayke/src/tinygo/tinygo/repro.go:7:6
func foo():
0:                                                                entry P:0 S:0
        t0 = nilPtrToArray()                                           *[2]byte
        t1 = *t0                                                        [2]byte
        t2 = println(2:int)                                                  ()
        return

# Name: command-line-arguments.bar
# Package: command-line-arguments
# Location: /home/ayke/src/tinygo/tinygo/repro.go:11:6
func bar():
0:                                                                entry P:0 S:0
        t0 = nilPtrToArray()                                           *[2]byte
        t1 = println(2:int)                                                  ()
        return

What did you see happen?

foo and bar are equivalent. However, they produce different output. foo results in a nil pointer dereference, while bar does not.

What did you expect to see?

I think foo and bar should have produced equivalent SSA.

I think the following part of the language spec is relevant here:

The expressions len(s) and cap(s) are constants if the type of s is an array or pointer to an array and the expression s does not contain channel receives or (non-constant) function calls; in this case s is not evaluated.

If I'm reading this correctly, the bar case is the correct way this code should be read. Also, when testing with go run, the Go compiler doesn't panic because of a nil pointer in either case.

Also see: tinygo-org/tinygo#4786

[adonovan]

The spec says:

The expression len(s) is constant if s is a string constant. The expressions len(s) and cap(s) are constants if the type of s is an array or pointer to an array and the expression s does not contain channel receives or (non-constant) function calls; in this case s is not evaluated. Otherwise, invocations of len and cap are not constant and s is evaluated.

Let's look at your two examples. In foo, there is a function call, therefore the argument must be evaluated, and should panic:

func foo() {
        println(len(*nilPtrToArray()))
}

In bar, there are no channel receives or function calls, so the len argument is not evaluated, and there is no panic:

func bar() {
        ptr := nilPtrToArray()
        println(len(*ptr))
}

So I believe x/tools/go/ssa is correct. Congratulations, you have found a bug in the compiler.

[Yeaseen]

@aykevl thanks. I appreciate you documenting tinygo-org/tinygo#4786 here. I found this first when the go2hx transpiler was producing different behavior.

[zigo101]

The ssa output is some surprising, but the execution behaviors are both correct.

Regard to channel receives or function calls, there are no differences between foo and bar.
Channel receives or function calls mean the one in the arguments.

var c = func() chan int {
	x := make(chan int, 1)
	x <- 123
	return x
}()
var s []byte
const X = len([1]int{<-c})
const Y = cap([1]int{len(s)}) 

[randall77]

This seems like a bug in the order pass. It rewrites

_ = len(*f())

to

tmp := f()
_ = len(*tmp)

Which is not a semantics-preserving transformation in this strange case.
We probably need a second temp to evaluate the arg to len in the cases where it is non-constant in the spec

tmp1 := f()
tmp2 := *tmp1
_ = len(tmp2)

[randall77]

A tricky case:

p := (*[4]int)(nil)
for range p { }

My read of the spec is that this shouldn't panic, as there's an implicit len in there.
Currently it doesn't panic, but my simple fix for this issue trips up on this new case.

[gopherbot]

Change https://go.dev/cl/658096 mentions this issue: cmd/compile: remove implicit deref from len(p) where p is ptr-to-array

[randall77]

I sent 2 CLs for this, which mostly fix it.
A 3rd CL will be needed to fix my last tricky case, the implicit len that happens in a range statement. I think we need to fold the range arg to a constant in that case (like we do for len). That requires more frontend knowhow than I have. (See hacky code in CL 657777).

[gopherbot]

Change https://go.dev/cl/658097 mentions this issue: cmd/compile: ensure we evaluate side effects of len() arg

[aykevl]

Thank you for looking into this!
I didn't expect this to be a compiler bug, but I guess yay for finding one. This is indeed a bit of a weird edge case.