cmd/compile: counter-intuitive comparison of zero-sized pointers wrapped in interfaces

[Merovius]

Go version

go version go1.22.0 linux/amd64

Output of go env in your module/workspace:

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

What did you do?

Playground:

package main

import "fmt"

func main() {
	a, b := new(struct{}), new(struct{})
	x, y := any(a), any(b)
	fmt.Println(a == b, x == y, x.(*struct{}) == y.(*struct{}))
}

What did you see happen?

false true false

What did you expect to see?

Either false false false or true true true.

The spec defines comparison for interfaces as:

Interface types that are not type parameters are comparable. Two interface values are equal if they have identical dynamic types and equal dynamic values or if both have value nil.

Now, from this definition, the observed behavior should clearly be impossible. The dynamic values are not equal - either before or after wrapping them into any. However, the interfaces compare as equal.

I suspect there is an optimization going on, where the comparison function stored in the rtype short-circuits for pointers to zero-sized values, based on the permission for all zero-sized values to have the same address. But that is only correct, if the compiler does the same short-circuiting for ==, in my opinion.

Originally mentioned on golang-nuts.

[Merovius]

Hm, on second thought, the spec allows this, strictly speaking:

Pointer types are comparable. Two pointer values are equal if they point to the same variable or if both have value nil. Pointers to distinct zero-size variables may or may not be equal.

I thought the exception was just that two zero-sized variables are allowed to have the same address, but if there is an exception for the pointer-comparison itself as well, that means a Go implementation would technically be allowed to return the result of a coin-flip, whenever such pointers are compared and literally any behavior here is correct.

TBQH, that still seems a pretty confusing situation. I would personally vote to at least in gc make this consistent (e.g. by making the comparison always true, regardless of the actual addresses). But it changes this from an implementation-bug into a working-as-confusingly-as-specified.

[bserdar]

@Merovius I don't think that part of the spec can be applied here. If a and b are pointers to a zero-sized value, then they are either always equal, or always different for a compilation of a program. That is:

fmt.Println(a==b)
fmt.Println(a==b)

Both printlns must print true, or false. It should not be the case that one prints true, and the other false.

The case here is: x, y := any(a), any(b) and a!=b but x==y . The problem is not with pointers to distinct zero-size variables, but with interfaces containing pointers to zero-size variables.

[mateusz834]

Funny enough printing the pointers, make it return true.

a, b := new(struct{}), new(struct{})
x, y := any(a), any(b)
fmt.Printf("%p %p\n", a, b)
fmt.Println(a == b, x == y, x.(*struct{}) == y.(*struct{})) // true true true

Also:

a, b := new(struct{}), new(struct{})
x, y := any(a), any(b)
runtime.KeepAlive(&a)
fmt.Println(a == b, x == y, x.(*struct{}) == y.(*struct{})) // true true false

a, b := new(struct{}), new(struct{})
x, y := any(a), any(b)
runtime.KeepAlive(&a)
runtime.KeepAlive(&b)
fmt.Println(a == b, x == y, x.(*struct{}) == y.(*struct{})) // true true true

a, b := new(struct{}), new(struct{})
x, y := any(a), any(b)
fmt.Println(uintptr(unsafe.Pointer(a))) // 824634001135
fmt.Println(uintptr(unsafe.Pointer(b))) // 824634232559
fmt.Println(a == b, x == y, x.(*struct{}) == y.(*struct{})) // false true false

[Merovius]

If a and b are pointers to a zero-sized value, then they are either always equal, or always different for a compilation of a program.

That is not something the spec guarantees, no.

That is: […]. Both printlns must print true, or false. It should not be the case that one prints true, and the other false.

It's certainly confusing, but it is working as specified. There is nothing in the spec saying "a comparison of two values must always return the same thing".

FTR, that's why I made the distinction above. There are two places where pointers to zero-sized values are special-cased:

1. It is allowed for any variables of zero size to have the same address.
2. A comparison of two pointers to a zero-sized value may or may not be equal.

Your intuition would be right, if only the first was the case: In that case, every variable has a (consistent) address and the pointer-comparison would always have to compare those addresses.

But with the second exception, the comparison can return literally anything. There is no qualification on that "may or may not".

[Merovius]

@bserdar To be clear, according to that spec sentence, it would be correct for a == a to be false. Confusing. But correct.

And note that this is not the only case where == is irreflexive. For example, x := math.NaN(); fmt.Println(x == x) is also false.

[mateusz834]

The current implementation seems to return true, but only when a and b escape to the heap:

var escapes *struct{}

func main() {
	a, b := new(struct{}), new(struct{})
	x, y := any(a), any(b)
	escapes = a
	escapes = b
	fmt.Println(a == b, x == y, x.(*struct{}) == y.(*struct{})) // true true true
}

./main.go:10:13: new(struct {}) escapes to heap
./main.go:10:28: new(struct {}) escapes to heap

[bserdar]

@Merovius I see the point about NaN, but note that the behavior of NaN is consistent. My point here is that a program should not evaluate a==b differently for each comparison instance. If a==b and nothing modifies them, then another comparison of a==b should return the same. What we are observing here is that a!=b, but any(a)==any(b).

[Merovius]

@bserdar If you want to argue that the program behaves incorrectly, you have to argue from the spec, not from your expectation. You say that comparisons "should" behave a certain way - but if the spec does not say that comparisons behave that way, the program behaves correctly.

Again, to be clear: I agree that it's confusing and that it should be fixed. But the program behaves in accordance with the language specification.

[liennie]

@Merovius

To be clear, according to that spec sentence, it would be correct for a == a to be false. Confusing. But correct.

I don't think that's the case. The spec talks about pointers to distinct zero-size variables. When comparing a to itself, both sides of the comparison point to the same variable, so the relevant part of the spec in this case is Two pointer values are equal if they point to the same variable and the result should always be true.

This also means that if you do something like this:

s := struct{}{}
a, b := &s, &s

a and b should also always be equal.

[Merovius]

@liennie fair enough. You are right.

[zigo101]

A bug introduced in Go 1.9.

package main

type T struct {}

func main() {
	var a, b = &T{}, &T{}
	var x, y interface{} = a, b
	println(a == b, x == y)
}

$ gotv 1.8. run main.go
[Run]: $HOME/.cache/gotv/tag_go1.8.7/bin/go run main.go
true true
$ gotv 1.9. run main.go
[Run]: $HOME/.cache/gotv/tag_go1.9.7/bin/go run main.go
false true