go: runtime: consider making "slice bounds out of range" messages more explicit
What version of Go are you using (go version)?
go version go1.11.4 linux/amd64
Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (go env)?
go env Output
GOARCH="amd64" GOBIN="" GOCACHE="/root/.cache/go-build" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOOS="linux" GOPATH="/usr/local/src/dev/go" GOPROXY="" GORACE="" GOROOT="/usr/local/go" GOTMPDIR="" GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64" GCCGO="gccgo" CC="gcc" CXX="g++" CGO_ENABLED="1" GOMOD="" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build225702417=/tmp/go-build -gno-record-gcc-switches"
What did you do?
a := make([]int, 0, 5)
fmt.Println(a[5:])
What did you expect to see?
Result must be same as for the following code:
a := make([]int, 5)
fmt.Println(a[5:])
What did you see instead?
Error: “panic: runtime error: slice bounds out of range”
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 15 (7 by maintainers)
I don’t think we should change the runtime panic messages, for two reasons:
(1) I’m sure that people are relying on the text of the existing messages in their programs. They shouldn’t be, but they are, and it’s not worth breaking them.
(2) Adding additional information (such as the bounds involved) has a cost in binary size and execution. With the current ABI, passing bounds to the runtime panic routines requires stack space, which might prevent elimination of the function prolog, which can have a substantive performance cost in hot code. And there’s always a binary size impact.
Perhaps the runtime panic message could be a bit more explicit. In particular, the issue here is that we’re slicing
[5:0], which breaks thelow <= highproperty.Aside from that, I don’t see what else there is to do in Go. The program is wrong, and the runtime is right to panic. I’ll leave the issue open for now to see if anyone has any opinions on improving the runtime panic messages.
Ah,
len(a) == 0, forgive my slowness. I think you’re completely right, and we can close this issue.I imagined that would be the case (2), but I wanted to make sure 😃
Are you sure? I think omitting the high index just means the length. The spec mentions it:
I’m not sure what to think of Go 1.7 changing the behavior of this code. Perhaps earlier Go versions behaved correctly and have since been broken. Or perhaps they misbehaved and have been fixed.
Reading the spec again, now I think I agree with @soslanco’s reading of it. My initial replies were muscle memory, as I think I’ve encountered very similar panics in the past.
Ah, sorry, it is misunderstanding. The compiler is right.
fmt.Println(a[5:])doesn’t work for it is equivalent tofmt.Println(a[5:0]). 😃Note that it says “upper index bound”. You can do:
That is, you can use a slice expression to extend length up to capacity. But arbitrary slice expressions outside of the length range aren’t allowed. Perhaps the spec could be made clearer, but I think it’s clear enough as it is. I’ll leave that to @griesemer.