4 ms·
> nil pointer dereference in closeConnIfStillIdle What happens here? Does Go suffer from boundary access issues that C has? You know, in Rust, you don't have t
by __pid_t 10y ago
> nil pointer dereference in closeConnIfStillIdle
What happens here? Does Go suffer from boundary access issues that C has? You know, in Rust, you don't have to worry about that, but is it the same for GO?
- travjones 10y agoI think it would produce a runtime error and return a stack trace. Someone more qualified than me should chime in though...
- justinsaccount 10y agoYes, like this: package main import "io" func main() { var foo io.Closer foo.Close() } justin@t420:/tmp$ go run nil.go panic: runtime error: invalid memory address or nil pointer dereference [signal 0xb code=0x1 addr=0x20 pc=0x401023] goroutine 1 [running]: panic(0x463ea0, 0xc82000a140) /usr/lib/go-1.6/src/runtime/panic.go:481 +0x3e6 main.main() /tmp/nil.go:7 +0x23 exit status 2
- kevinmgranger 10y agoThe goroutine panics. Nil dereferences are recoverable from[1], but I'm not sure how many people expect standard library code to panic. [1]: https://play.golang.org/p/hjfaNQbOBO https://play.golang.org/p/hjfaNQbOBO
- deleted 10y ago[deleted]
- pcwalton 10y agoGo has null pointers, unlike Rust. Dereferencing a null reference type generally panics, but there are some random exceptions (e.g. indexing a nil map returns a zero value of the appropriate type).
- ben_jones 10y agoI've run into intermittent issues with net/http (such as the defaults for HttpClient causing application failures in production). It's just a spot you learn to pay attention to. I'm glad they're fixing some of the bugs in the code because otherwise it is an incredible part of the STD lib.
- masklinn 10y ago> Does Go suffer from boundary access issues that C has? It has NPE (like Java or C#), though in some conditions it'll behave more like Objective-C.