-
Notifications
You must be signed in to change notification settings - Fork 30.7k
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
expose Z_STREAM_END #26624
expose Z_STREAM_END #26624
Conversation
Here is my toy demonstration of what I need to do streaming zip file decompression. I compresses a stream of 100 characters. I then consume that deflated buffer (write them into a deflateRaw stream) in chunks to simulate downloading them piecemeal. Then I also write 6 bytes of junk into the deflateRaw stream to simulate zlib tossing bytes written after the deflate stream has terminated. I detect the deflate stream has terminated in
Result:
|
// This applies to streams where we don't check data past the end of | ||
// what was consumed; that is, everything except Gunzip/Unzip. | ||
self.push(null); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removing this is a breaking change, the test added in #26363 should fail (once the linter issue has been fixed here).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I didn't realize this had already gone out the door. Nor did I realize that I should be trapping for the end
event and not the finish
event!
Thanks for the code review!
Done in #26363 |
Zlib streams self terminate and need a way to report that case.
I've use the same convention as is used to report the number of decompressed bytes (
bytesWritten
). The number of decompressed bytes cannot be reported via a first class stream abstraction. Similarly, stream self termination cannot be reported via a first class stream abstraction. So I figured it made sense to use the same mechanism to report both out-of-stream-abstraction conditions. Also, kinda makes sense: The state of the write of a chunk of data to inflate includes not only how much was consumed during inflation but also whether the EOF was encountered.This feature is necessary for streaming decompression of zip files (say, during download). A zip file is partitioned into headers followed by deflated streams. The headers do not necessarily have to contain the length of the stream. So the zlib inflate stream needs to report the deflated stream's EOF up to the unzip algorithm. That way the unzip algorithm knows when to stop writing bytes to the inflate stream (and then do the accounting to know how many bytes were tossed by the inflate stream and backup to that position in the download stream to look for the next header).
Will do checklist pending discussion on #26603.
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes