-
Notifications
You must be signed in to change notification settings - Fork 18.4k
Closed
Labels
FrozenDueToAgeNeedsFixThe path to resolution is known, but the work has not been done.The path to resolution is known, but the work has not been done.
Milestone
Description
I have a package that uses bufio.Reader to decode protocol messages. It implements
trace debugging by writing all messages through an io.Pipe(). I was surprised to find
that the first 100 0-length writes were ignored by the bufio.Reader.fill method, as
the documentation explicitly states
The bytes are taken from at most one Read on the underlying Reader, hence
n may be less than len(p).
I would like to suggest a documentation change to indicate that zero-length reads are
not counted.
What version of Go are you using (go version)?
go version go1.7 linux/amd64
What operating system and processor architecture are you using (go env)?
GOARCH="amd64"
GOBIN="/usr/local/bin"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/"
GORACE=""
GOROOT="/go"
GOTOOLDIR="/go/pkg/tool/linux_amd64"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build706953720=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
What did you do?
A zero-length write to an io.PipeWriter, whose corresponding
io.PipeReader was read through a bufio.Reader. The following
simplified program illustrates the issue: https://play.golang.org/p/lI14R5CMQ-
What did you expect to see?
The program should print one item for every write to the pipe:
1 foo
2 bar
3
4
5
6 baz
What did you see instead?
The bufio.Reader ignored the 0-byte reads.
1 foo
2 bar
3 baz
Metadata
Metadata
Assignees
Labels
FrozenDueToAgeNeedsFixThe path to resolution is known, but the work has not been done.The path to resolution is known, but the work has not been done.