[state_machine]

The 14 issues tagged 1.7.1:

  net: retry DNS lookups before failure?
  io: endless loop in MultiReader in Go 1.7
  path/filepath: EvalSymlinks is broken for relative paths on Windows
  net/http/httputil: Proxy terminates HTTP/2 stream before reading response body.
  hash/crc32: wrong output for unaligned input on s390x
  cmd/compile: incorrect assignment to uint64 via pointer converted to *uint16 (new in 1.7)
  doc: deprecation message for Transport.CancelRequest is not correct Documentation
  compress/zlib: Writer appears to ignore underlying writer errors at times.
  net: NATs client can't connect to server when client built with go1.7: "dial tcp: no suitable address found"
  doc: go1.7 release notes include typo for TLSConfig.NextProtos Documentation
  reflect: ChanOf makes "han" types instead of "chan" types
  x/mobile: Binding go mobile framework on iOS 9 with golang1.7rc6 crash when call debug.FreeOSMemory()
  net/http: nil pointer dereference in closeConnIfStillIdle
  website: retina favicon Suggested

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

[kid0m4n]

We were bit by the `closeConnIfStillIdle` bug as we didn't expect the stdlib to panic like that (also something you cannot recover from, as it happens in a goroutine which you didn't create.)