I introduced this problem in change set 33 when I redefined
RejectionReason from a uint32 to an int. I have added a test
to verify the message can be marshaled correctly.
This was a bit hard to track down as the recover in clientConn
mainLoop would catch the panic and shutdown the connection. We
probably shouldn't be using panic inside marshal/unmarshal, at
least not without a way to let the user know why the recover
logic tripped.
R=agl, kardianos, gustav.paul
CC=golang-dev
https://golang.org/cl/6210063
Manual edits to README.
Moved from main Go repository, deleted Makefiles, ran gofix -r go1rename.
Tested with: go test code.google.com/p/go.crypto/...
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/5564059