__pid_t on Go 1.7.1 Released

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?

pcwalton 10y

Go 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

I'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.

travjones 10y

I think it would produce a runtime error and return a stack trace. Someone more qualified than me should chime in though...

justinsaccount 10y

Yes, 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

The 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

masklinn 10y

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.

Comments