Rietveld Code Review Tool
Help | Bug tracker | Discussion group | Source code | Sign in
(19)

Issue 77580046: code review 77580046: strings: fix Reader.UnreadRune (Closed)

Can't Edit
Can't Publish+Mail
Start Review
Created:
10 years, 2 months ago by ruiu
Modified:
10 years, 2 months ago
Reviewers:
gobot, josharian, bradfitz
CC:
golang-codereviews, bradfitz
Visibility:
Public.

Description

strings, bytes: fix Reader.UnreadRune UnreadRune should return an error if previous operation is not ReadRune. Fixes issue 7579.

Patch Set 1 #

Patch Set 2 : diff -r 1ddce2d9ee32 https://code.google.com/p/go #

Patch Set 3 : diff -r 1ddce2d9ee32 https://code.google.com/p/go #

Patch Set 4 : diff -r 1ddce2d9ee32 https://code.google.com/p/go #

Patch Set 5 : diff -r 1ddce2d9ee32 https://code.google.com/p/go #

Patch Set 6 : diff -r 1ddce2d9ee32 https://code.google.com/p/go #

Patch Set 7 : diff -r 1ddce2d9ee32 https://code.google.com/p/go #

Unified diffs Side-by-side diffs Delta from patch set Stats (+64 lines, -4 lines) Patch
M src/pkg/bytes/reader.go View 1 2 3 4 5 6 5 chunks +5 lines, -2 lines 0 comments Download
M src/pkg/bytes/reader_test.go View 1 2 3 4 5 6 1 chunk +27 lines, -0 lines 0 comments Download
M src/pkg/strings/reader.go View 1 5 chunks +5 lines, -2 lines 0 comments Download
M src/pkg/strings/strings_test.go View 1 2 3 4 1 chunk +27 lines, -0 lines 0 comments Download

Messages

Total messages: 15
ruiu
Hello golang-codereviews@googlegroups.com, I'd like you to review this change to https://code.google.com/p/go
10 years, 2 months ago (2014-03-19 06:31:36 UTC) #1
bradfitz
Is bytes.Reader okay? The two share almost identical implementations. On Mar 18, 2014 11:31 PM, ...
10 years, 2 months ago (2014-03-19 06:38:13 UTC) #2
ruiu
Ah, no. I'll apply this change to bytes.Reader as well. Thank you for pointing it ...
10 years, 2 months ago (2014-03-19 06:40:02 UTC) #3
bradfitz
Thanks. I will review tomorrow. On Mar 18, 2014 11:40 PM, "Rui Ueyama" <ruiu@google.com> wrote: ...
10 years, 2 months ago (2014-03-19 06:41:49 UTC) #4
ruiu
Hello golang-codereviews@googlegroups.com, bradfitz@golang.org (cc: golang-codereviews@googlegroups.com), Please take another look.
10 years, 2 months ago (2014-03-19 06:51:56 UTC) #5
bradfitz
LGTM
10 years, 2 months ago (2014-03-19 15:59:02 UTC) #6
bradfitz
*** Submitted as https://code.google.com/p/go/source/detail?r=358e2b416518 *** strings, bytes: fix Reader.UnreadRune UnreadRune should return an error if ...
10 years, 2 months ago (2014-03-19 16:01:01 UTC) #7
gobot
This CL appears to have broken the linux-amd64-race builder. See http://build.golang.org/log/2d924df645a4978ae681f709fdb30630554d42aa
10 years, 2 months ago (2014-03-19 16:05:05 UTC) #8
josharian
That breakage looks real, and related: ================== WARNING: DATA RACE Write by goroutine 26: bytes.(*Reader).ReadAt() ...
10 years, 2 months ago (2014-03-19 18:10:40 UTC) #9
ruiu
Does this buildbot have a special flag to enable data race detection? I can't reproduce ...
10 years, 2 months ago (2014-03-19 18:21:09 UTC) #10
josharian
Try: go test -race archive On Wed, Mar 19, 2014 at 2:20 PM, Rui Ueyama ...
10 years, 2 months ago (2014-03-19 18:28:12 UTC) #11
ruiu
It looks like the reason of the failure is that the test does not assume ...
10 years, 2 months ago (2014-03-19 18:31:49 UTC) #12
bradfitz
Yes, this is real. Any io.ReaderAt is allowed to be called concurrently from many goroutines. ...
10 years, 2 months ago (2014-03-19 18:31:57 UTC) #13
bradfitz
On Wed, Mar 19, 2014 at 11:31 AM, Rui Ueyama <ruiu@google.com> wrote: > It looks ...
10 years, 2 months ago (2014-03-19 18:32:54 UTC) #14
ruiu
10 years, 2 months ago (2014-03-19 18:34:10 UTC) #15
Thanks, Brad.

I'll send you a patch to fix it now. Hold on.

Sorry for the breakage.


On Wed, Mar 19, 2014 at 11:32 AM, Brad Fitzpatrick <bradfitz@golang.org>wrote:

>
>
>
> On Wed, Mar 19, 2014 at 11:31 AM, Rui Ueyama <ruiu@google.com> wrote:
>
>> It looks like the reason of the failure is that the test does not assume
>> that ReadAt will mutate the receiver. After my patch, ReadAt sets -1 to
>> unread rune variable, which I believe caused this breakage.
>>
>> Should we allow UnreadRune after ReadAt? If we allow it ReadAt does not
>> have to alter the state of the receiver.
>>
>
> Yes, ReadAt doesn't mutate any state (notably the offset or consume any
> data), so that's fine to call ReadAt then UnreadRune.
>
>
>
Sign in to reply to this message.

Powered by Google App Engine
RSS Feeds Recent Issues | This issue
This is Rietveld f62528b