It happens with larger buffers too, though: https://play.golang.org/p/0pQq8eungQ
On Tue, Dec 19, 2017 at 10:13 PM Ian Lance Taylor <i...@golang.org> wrote: > On Tue, Dec 19, 2017 at 11:08 AM, Paul Boyd <boyd.pa...@gmail.com> wrote: > > > > Sorry if this is a dumb question that's been answered before, but I can't > > find anything about it. > > > > I'm calling Grow() on a bytes.Buffer and I thought that would increase > Cap() > > and the size of the underlying []byte. But, it doesn't seem to: > > https://play.golang.org/p/3j8YCpB59s That example works if I call Grow() > > with a value more than Cap()*2, but anything less and Cap() remains > > unchanged. > > > > Some background, if it helps, I was attempting to re-use bytes.Buffer > > objects with sync.Pool. But the data I'm dealing with is a variable > size, so > > if I get back a buffer that's too small I'm calling Grow() for the > > difference. Subsequently using Bytes()[:expectedSize], which sometimes > > panics. This is basically what was going on: > > https://play.golang.org/p/gBvcvs79T7 > > > > Am I just misusing bytes.Buffer? Is calling Grow() with a value less than > > Cap() unsupported? What am I missing? > > For efficiency for small buffers, a bytes.Buffer starts out with an > internal 64 byte buffer. You aren't going to see interesting results > from Grow unless you first Grow the buffer past that size. > > Ian > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
