Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bufio: uninitialised buffer in Writer causes panics and infinite loops #18211

Closed
n10v opened this issue Dec 6, 2016 · 4 comments
Closed

bufio: uninitialised buffer in Writer causes panics and infinite loops #18211

n10v opened this issue Dec 6, 2016 · 4 comments

Comments

@n10v
Copy link
Contributor

n10v commented Dec 6, 2016

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
Copy link
Member

myitcv commented Dec 6, 2016

@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
Copy link
Contributor Author

n10v commented Dec 6, 2016

@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
Copy link
Member

myitcv commented Dec 6, 2016

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
Copy link
Contributor

Closing because there is nothing to fix.

@golang golang locked and limited conversation to collaborators Dec 6, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants