Skip to content

Make BufferedReader propagate 0-byte long reads. #11022

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

Merged
merged 2 commits into from
Dec 23, 2013
Merged

Conversation

spaolacci
Copy link
Contributor

Could prevent callers from catching the situation and lead to e.g early
iterator terminations (cf. Reader::read_byte) since None is only to
be returned only on EOF.

Could prevent callers from catching the situation and lead to e.g early
iterator terminations (cf. `Reader::read_byte') since `None' is only to
be returned only on EOF.
@alexcrichton
Copy link
Member

I don't really understand why the check for an empty buffer moved lower, it seems like the condition you want is to have if available.len() == 0 && self.inner.reader.eof() { return None; }.

Additionally, this is a tricky case which definitely needs a test.

@spaolacci
Copy link
Contributor Author

I definitely agree with the test requirement. The reason for moving down the condition is (/was) to avoid multi-borrowing of (*self).inner. I honestly didn't find any easier way to bypass the following situation

buffered.rs:121:39: 121:49 error: cannot borrow `(*self).inner` as mutable more than once at a time
buffered.rs:121             if available.len() == 0 && self.inner.eof() {
                                                       ^~~~~~~~~~
buffered.rs:120:28: 120:33 note: second borrow of `(*self).inner` as mutable occurs here
buffered.rs:120             let available = self.fill();
                                            ^~~~~

I'm quite new to the language (to say the least), so I'm obviously open to any lead/suggestion with doing it any other way (or with just opening a bug and letting the patch down to not make you loose too much of your time).

@alexcrichton
Copy link
Member

Ah I can see where that would be a problem, r+ with a test!

The two `Some(0)' used to be `None' before the patch, a zero-byte long
read exhausting a reader (and thereafter) still produce a `None'.
bors added a commit that referenced this pull request Dec 23, 2013
Could prevent callers from catching the situation and lead to e.g early
iterator terminations (cf. `Reader::read_byte`) since `None` is only to
be returned only on EOF.
@bors bors closed this Dec 23, 2013
@bors bors merged commit ee887d7 into rust-lang:master Dec 23, 2013
@spaolacci spaolacci deleted the 0read branch December 28, 2013 09:24
flip1995 pushed a commit to flip1995/rust that referenced this pull request Jun 30, 2023
Avoid linting `extra_unused_type_parameters` on procedural macros

Don't lint `extra_unused_type_parameters` if code was generated by procedural macro.

This PR fixes rust-lang/rust-clippy#11014

changelog: [`extra_unused_type_parameters`] avoid linting macro-generated code
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants