I was being too clever, as usual. Write the obvious code to make sure
that when we grow the buffer we don't overflow.
Change-Id: I1641831177b0bb8a89ab6e9bcabccf6c2fcfe1d2
Reviewed-on: https://go-review.googlesource.com/14781
Reviewed-by: Minux Ma <minux@golang.org>
Add Scanner.Buffer, which lets the user give a buffer to
the scanner and set the maximum token size.
We call it Buffer not SetBuffer for consistency with Split, which
perhaps should have been called SetSplit; too late regardless.
Both Buffer and Split panic if they are called after Scan. The
panic in Split is new, but the comment on the method already
said it needed to be called first, so we might as well add the
verification while we're doing it for Buffer.
This method allows precise user control of storage.
Fixes#11702.
Change-Id: I80e3d0e3830562fdabd4f7b08f322e1378248c39
Reviewed-on: https://go-review.googlesource.com/14599
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: roger peppe <rogpeppe@gmail.com>
The default value for error is nil so there is no need to assign this
value here.
Change-Id: I4714ef7607996ccbf91b704390e1d1d39ee3847b
Reviewed-on: https://go-review.googlesource.com/12355
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reader.Discard is the complement to Peek. It discards the next n bytes
of input.
We already have Reader.Buffered to see how many bytes of data are
sitting available in memory, and Reader.Peek to get that that buffer
directly. But once you're done with the Peek'd data, you can't get rid
of it, other than Reading it.
Both Read and io.CopyN(ioutil.Discard, bufReader, N) are relatively
slow. People instead resort to multiple blind ReadByte calls, just to
advance the internal b.r variable.
I've wanted this previously, several people have asked for it in the
past on golang-nuts/dev, and somebody just asked me for it again in a
private email. There are a few places in the standard library we'd use
it too.
Change-Id: I85dfad47704a58bd42f6867adbc9e4e1792bc3b0
Reviewed-on: https://go-review.googlesource.com/2260
Reviewed-by: Russ Cox <rsc@golang.org>
The new rules for split functions mean that we are exposed
to the common bug of a function that loops forever at EOF.
Pick these off by shutting down the scanner if too many
consecutive empty tokens are delivered.
Fixes#9020.
LGTM=rsc, adg
R=golang-codereviews, rsc, adg, bradfitz
CC=golang-codereviews
https://golang.org/cl/169970043
