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
Labels
FeatureRequest Issues asking for a new feature that does not need a proposal.
Milestone

Comments

@josharian
Copy link
Contributor

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

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

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

Ah ok, that makes sense now.

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

@josharian
Copy link
Contributor Author

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

@nightlyone
Copy link
Contributor

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
@bradfitz bradfitz added the FeatureRequest Issues asking for a new feature that does not need a proposal. label Feb 1, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
FeatureRequest Issues asking for a new feature that does not need a proposal.
Projects
None yet
Development

No branches or pull requests

4 participants