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

testing/iotest: add two new readers #9466

Open
josharian opened this issue Dec 29, 2014 · 5 comments
Open

testing/iotest: add two new readers #9466

josharian opened this issue Dec 29, 2014 · 5 comments
Assignees
Milestone

Comments

@josharian
Copy link
Contributor

@josharian josharian commented Dec 29, 2014

Just in case there is interest, here are two other badly-behaved reader types that might make useful additions to testing/iotest:

// ZeroNilReader returns 0, nil on every second read. Other calls to read succeed.
func ZeroNilReader(r io.Reader) io.Reader

// CorruptingReader returns a Reader that modifies any unused portion of the byte slice passed to Read.
// It is useful in conjunction with OneByteReader.
func CorruptingReader(r io.Reader) io.Reader
@nightlyone
Copy link
Contributor

@nightlyone nightlyone commented Dec 29, 2014

I am not sure, the CorruptingReader is still within the contract of an io.Reader. It appears quite common to pass the lower and the upper half of a buffer represented by a byte slice to two different Read() calls in order to save the copying.

Could you provide a usage sample demonstrating what kind of error/good behavior that would expose?

@josharian
Copy link
Contributor Author

@josharian josharian commented Dec 29, 2014

From the io.Reader docs: "Even if Read returns n < len(p), it may use all of p as scratch space during the call." The CorruptingReader would be checking that the caller doesn't rely on Read leaving the buffer untouched aside from the part containing newly read data.

@nightlyone
Copy link
Contributor

@nightlyone nightlyone commented Dec 29, 2014

Ah ok, that makes sense now.

I understood, you plan to corrupt p[len(p):cap(p)] instead.

@josharian
Copy link
Contributor Author

@josharian josharian commented Dec 29, 2014

Actually, the plan is to corrupt p[n:].

@nightlyone
Copy link
Contributor

@nightlyone nightlyone commented Dec 29, 2014

Both sound like very useful additions to me, if you clear up the comment on what portion "unused portion" really is.

@rsc rsc added this to the Unplanned milestone Apr 10, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.