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

Allow pub access to underlying 'Read' member of Take or Chain #29067

Closed
peter-bertok opened this issue Oct 15, 2015 · 5 comments
Closed

Allow pub access to underlying 'Read' member of Take or Chain #29067

peter-bertok opened this issue Oct 15, 2015 · 5 comments
Labels
E-help-wanted Call for participation: Help is requested to fix this issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@peter-bertok
Copy link

I asked this as a question on StackOverflow, and it was suggested that I raise an issue.

I'm writing a Rust implementation of the Google Brotli decompression algorithm, which uses a fixed number of "implicit zeroes" at the end of the stream to enable certain optimisations.

The Google C implementation does this using a spaghetti code of various counters, but I'd like to use the adaptors in the Rust std::io library instead. Something like:

pub struct StreamBitReader<R> {
    reader: Chain<R,Take<Repeat>>,
    ...
}

where 'R' is the underlying Read that the bit reader struct is wrapping. However, there are a number of cases where the decompression algorithm checks to see if it has "overrun" the stream, and it does this by checking the number of implicit zero bytes that have been read. This appears to be impossible in safe Rust, as there is no way to obtain a reference to the underlying components of Chain, unless I'm missing something.

When Chain is constructed, it takes ownership of (moves) the two Read structs, which then are hidden in private members.

Is there any way to construct the Take<Repeat> part such that I can continue to access the limit() fn of Take even after the Chain adaptor takes ownership?

If not, then there ought to be either public members or functions that allow access to the base Read members of all such adaptors, to allow this type of code.

@sfackler
Copy link
Member

That seems pretty reasonable. We already have those kinds of accessors on other adaptors like BufferedReader and BufferedWriter.

@sfackler sfackler added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. A-io labels Oct 15, 2015
@brson
Copy link
Contributor

brson commented Mar 23, 2017

Does libs team care about this for completeness?

@alexcrichton
Copy link
Member

Yes seems fine to implement to me

@aturon aturon added E-help-wanted Call for participation: Help is requested to fix this issue. and removed I-nominated labels Mar 28, 2017
@aturon
Copy link
Member

aturon commented Mar 28, 2017

Libs team is 👍 on this, please send a PR!

@SergioBenitez
Copy link
Contributor

I've started working on this and will have an implementation soon!

SergioBenitez added a commit to SergioBenitez/rust that referenced this issue Apr 24, 2017
frewsxcv added a commit to frewsxcv/rust that referenced this issue Apr 25, 2017
Add internal accessor methods to io::{Chain, Take}.

Resolves rust-lang#29067.
arielb1 pushed a commit to arielb1/rust that referenced this issue Apr 25, 2017
Add internal accessor methods to io::{Chain, Take}.

Resolves rust-lang#29067.
arielb1 pushed a commit to arielb1/rust that referenced this issue Apr 25, 2017
Add internal accessor methods to io::{Chain, Take}.

Resolves rust-lang#29067.
frewsxcv added a commit to frewsxcv/rust that referenced this issue Apr 26, 2017
Add internal accessor methods to io::{Chain, Take}.

Resolves rust-lang#29067.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
E-help-wanted Call for participation: Help is requested to fix this issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

6 participants