[__pid_t]

> 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]

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]

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]

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

[justinsaccount]

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]

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]

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