bufio: uninitialised buffer in Writer causes panics and infinite loops

[n10v]

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

go version go1.7.3 darwin/amd64

What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/albert/go"
GORACE=""
GOROOT="/Users/albert/.gostable"
GOTOOLDIR="/Users/albert/.gostable/pkg/tool/darwin_amd64"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/wp/sytm29yd1d1dclmf01xgvqbw0000gn/T/go-build808633337=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"

What did you do?

If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.

If one will create buffer without using a constructor (buf := new(bufio.Writer)), then the further writes will cause panics or infinite loops depending on method one uses.
E.g. https://play.golang.org/p/LBrzU6xw2Z

What did you expect to see?

Buffer will be initialised, if it's not, and the further writes will be successful.

What did you see instead?

buf.WriteString causes an infinite loop: https://play.golang.org/p/LBrzU6xw2Z,
buf.WriteRune causes panic: https://play.golang.org/p/MAioIyqCJs,
buf.WriteByte causes panic: https://play.golang.org/p/e-JIMtF_tc,
and so on.

[myitcv]

@BoGeM the documented way to create a bufio.Writer is via bufio.NewWriter (or bufio.NewWriterSize)

Please also consider asking questions like this in the go-nuts mailing list or other help forums as a first port of call. If the behaviour you are seeing is then confirmed as a bug/issue it can easily be re-raised here in the issue tracker, referencing the original thread.

[n10v]

@myitcv but user can also initalize writer by calling new method. The language permits doing this, so why not? In some cases it's the only logic way.
For example in pool of bufio.Writers. Pool can create new Writer by new(bufio.Writer), but it leads to this bug. So developer should write bufio.NewWriter(nil). Concrete example

Ok, sorry for this. Next time I will do so.
But many times I post some question or issue in go-nuts and it finds no answer at all :(

[myitcv]

The language permits doing this, so why not?

I've always followed the guidance laid out here:

https://golang.org/doc/effective_go.html#allocation_new

Since the memory returned by new is zeroed, it's helpful to arrange when designing your data structures that the zero value of each type can be used without further initialization. This means a user of the data structure can create one with new and get right to work. For example, the documentation for bytes.Buffer states that "the zero value for Buffer is an empty buffer ready to use." Similarly, sync.Mutex does not have an explicit constructor or Init method. Instead, the zero value for a sync.Mutex is defined to be an unlocked mutex.

Hence, I first check to see whether there is an explicit constructor or Init method; if there is neither and there is documentation that confirms the zero value is "ready to use" then I feel safe in doing so. Some data structures cannot be designed in such a way that the zero value is "useful."

Ok, sorry for this. Next time I will do so.

I wouldn't say an apology is needed 😄 I make the comment just to try and help keep the issue tracker focussed on things that are known to be issues (if you look at the thousands of people who potentially get notified of each issue)

[ianlancetaylor]

Closing because there is nothing to fix.