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

cmd/compile: impossible slice access is compiled in spite of always panicking #27250

Closed
mariecurried opened this issue Aug 26, 2018 · 2 comments

Comments

@mariecurried
Copy link

mariecurried commented Aug 26, 2018

What version of Go are you using (go version)?

go version go1.11 windows/amd64

What operating system and processor architecture are you using (go env)?

set GOARCH=amd64
set GOBIN=
set GOCACHE=...
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=...
set GOPROXY=
set GORACE=
set GOROOT=C:\Go
set GOTMPDIR=
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=... -gno-record-gcc-switches

What did you do?

I compiled the following function: https://play.golang.org/p/Opd10xBfZKu

What did you expect to see?

I expected the code not to compile, because the position len(slice)*2 can never be a valid position in the slice.

What did you see instead?

The code was compiled with bounds checks and always panics because of index out of range (the code produced is correct, but what I think is that it shouldn't be compiled in the first place - always results in panic).

Edit: after further testing, I noticed that the same happens for len(slice)+n, where n is a positive integer.

@cherrymui
Copy link
Member

The spec (https://golang.org/ref/spec#Index_expressions) says

For a of slice type S:
if x is out of range at run time, a run-time panic occurs

So it should be a run-time panic, instead of compile-time error. I think this works as intended.

@ianlancetaylor
Copy link
Member

Yes, this is correct behavior. We don't want to be a compilation error; the statement might never be executed.

@golang golang locked and limited conversation to collaborators Aug 27, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants