Skip to content

gccgo: dereference of nil pointer to zero-width type does not panic #31151

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.

Sign up for GitHub

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

Jump to bottom
Open
mdempsky opened this issue Mar 29, 2019 · 5 comments
Open

gccgo: dereference of nil pointer to zero-width type does not panic #31151

mdempsky opened this issue Mar 29, 2019 · 5 comments
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Gccgo

Comments

@mdempsky
Copy link
Contributor

The Go spec says "For an operand x of pointer type *T, the pointer indirection *x denotes the variable of type T pointed to by x. If x is nil, an attempt to evaluate *x will cause a run-time panic."

This program correctly panics with cmd/compile, but does not with gccgo 8.0.0:

package main

func main() {
	var p *struct{}
	*p = *p
}

/cc @ianlancetaylor
@gopherbot gopherbot added this to the Gccgo milestone Mar 29, 2019
@gopherbot
Copy link
Contributor

Change https://golang.org/cl/170013 mentions this issue: compiler: require nil check when dereferecing a pointer to zero-sized type

@cherrymui
Copy link
Member

The problem seems not specific to zero-sized type.

package main

func main() {
	var p *struct{ x int }
	*p = *p
}

This also does not panic. I think as long as the type is not big (>4096 bytes), if the backend somehow optimizes the dereference away, it will not panic.

@ianlancetaylor
Copy link
Member

I think you're right. But I don't particularly want to force a nil check for all pointer dereferences. In principle we could do it only if we think the backend might eliminate the dereference.

@ianlancetaylor ianlancetaylor added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Mar 30, 2019
@gopherbot
Copy link
Contributor

Change https://golang.org/cl/176459 mentions this issue: compiler: improve escape analysis on interface conversions

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/176579 mentions this issue: test: use a real use function in nilptr2.go

gopherbot pushed a commit that referenced this issue May 11, 2019
@cherrymui
test: use a real use function in nilptr2.go
ce5ae2f 
Adjust the dummy use function to a real use. As suggested by the
println calls in the test, nilptr2.go supposes to check that a
used nil pointer dereference panics. This use function is not
real enough so an optimized compiler such as gccgo could
eliminate the call.

The spec requires that even a dummy use would cause a panic.
Unfortunately, due to #31151 this is not true for gccgo at -O1 or
above.

Change-Id: Ie07c8a5969ab94dad82d4f7cfec30597c25b7c46
Reviewed-on: https://go-review.googlesource.com/c/go/+/176579
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Gccgo
Development

No branches or pull requests
4 participants
@mdempsky @ianlancetaylor @gopherbot @cherrymui