Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

runtime: consider making "slice bounds out of range" messages more explicit #29435

Closed
soslanco opened this issue Dec 27, 2018 · 15 comments

Comments

Projects
None yet
4 participants
@soslanco
Copy link

commented Dec 27, 2018

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"

@mvdan

This comment has been minimized.

Copy link
Member

commented Dec 27, 2018

The slice indexes must be within the length of the slice, not its capacity. Please read the spec more carefully: https://golang.org/ref/spec#Slice_expressions

@mvdan mvdan closed this Dec 27, 2018

@soslanco

This comment has been minimized.

Copy link
Author

commented Dec 27, 2018

For arrays or strings, the indices are in range if 0 <= low <= high <= len(a), otherwise they are out of range. For slices, the upper index bound is the slice capacity cap(a) rather than the length.

@mvdan

This comment has been minimized.

Copy link
Member

commented Dec 27, 2018

Note that it says "upper index bound". You can do:

a := make([]int, 0, 5)
fmt.Println(a[:5])

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.

@mvdan mvdan reopened this Dec 27, 2018

@mvdan mvdan added the NeedsDecision label Dec 27, 2018

@mvdan mvdan changed the title Error while using slice without high index spec: clarify slice expression index limits for slices Dec 27, 2018

@mvdan mvdan added the Documentation label Dec 27, 2018

@soslanco

This comment has been minimized.

Copy link
Author

commented Dec 27, 2018

low<=high
low = cap(a)

  1. why the following code works fine:
a := make([]int, 0, 5)
fmt.Println(a[5:5])

and

a := make([]int, 0, 5)
fmt.Println(a[5:])

does't

@go101

This comment has been minimized.

Copy link

commented Dec 27, 2018

I have an impression that the low index in s[low:high] must not be larger than len(s) for a long time.
I just rechecked Go spec, I was wrong.

fmt.Println(a[5:]) should work fine, it is a bug at least since Go SDK 1.7.

@go101

This comment has been minimized.

Copy link

commented Dec 27, 2018

Then one section in my article should be wrong. And one SSA optimization in gc is too conservative.

@go101

This comment has been minimized.

Copy link

commented Dec 27, 2018

Ah, sorry, it is misunderstanding. The compiler is right.

fmt.Println(a[5:]) doesn't work for it is equivalent to fmt.Println(a[5:0]). :)

@go101

This comment has been minimized.

Copy link

commented Dec 27, 2018

But my former impression for the slice rule was really wrong.

@mvdan

This comment has been minimized.

Copy link
Member

commented Dec 27, 2018

fmt.Println(a[5:]) doesn't work for it is equivalent to fmt.Println(a[5:0]). :)

Are you sure? I think omitting the high index just means the length. The spec mentions it:

a[2:] // same as a[2 : len(a)]

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.

@mvdan

This comment has been minimized.

Copy link
Member

commented Dec 27, 2018

Are you sure? I think omitting the high index just means the length.

Ah, len(a) == 0, forgive my slowness. I think you're completely right, and we can close this issue.

@soslanco

This comment has been minimized.

Copy link
Author

commented Dec 27, 2018

Yep!
A missing low index defaults to zero; a missing high index defaults to the length of the sliced operand.

@mvdan

This comment has been minimized.

Copy link
Member

commented Dec 27, 2018

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 the low <= high property.

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.

@mvdan mvdan removed the Documentation label Dec 27, 2018

@mvdan mvdan changed the title spec: clarify slice expression index limits for slices runtime: consider making "slice bounds out of range" messages more explicit Dec 27, 2018

@josharian

This comment has been minimized.

Copy link
Contributor

commented Dec 27, 2018

I'll leave the issue open for now to see if anyone has any opinions on improving the runtime panic messages.

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.

@mvdan

This comment has been minimized.

Copy link
Member

commented Dec 27, 2018

I imagined that would be the case (2), but I wanted to make sure :)

@mvdan mvdan closed this Dec 27, 2018

@soslanco

This comment has been minimized.

Copy link
Author

commented Dec 27, 2018

Thanks for all your advice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.