-
Notifications
You must be signed in to change notification settings - Fork 49
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
miniz_oxide::inflate::stream::inflate consumes more bytes than it actually used #158
Comments
This underlying miniz_oxide/miniz_oxide/src/inflate/core.rs Lines 1172 to 1178 in 0a33eff
But miniz_oxide/miniz_oxide/src/inflate/stream.rs Line 308 in 0a33eff
And this output buffer size is 32768 ( |
Maybe there is no bug, I made decompression work with flate2 using miniz_oxide backend: rust-lang/flate2-rs#436 |
@oyvindln I made But this requires trying to |
I believe it is possible to have all of your input "consumed" yet still have remaining bytes to retrieve via zlib, too. It may be only a byte or two. But if you're not checking the state variables for "done". you may still be leaving pieces behind. |
Hm, would have to investigate that as well then |
Seeing as this seems to be how the original miniz behaves and is designed around I think it makes sense to keep this as the default behaviour (though document it properly. I think it would be doable to make a separate variant of the function by using a non-circular internal buffer that would limit the buffer in the inner call to decompress to the same size as the output buffer so it behaves similarly to zlib though. It's possible it would have slightly different performance characteristics but I can't tell without implementing it. |
Here is a failing test:
Output buffer is only 8 bytes in size, but
miniz_oxide
consumes the whole input buffer anyway.This causes the issue in flate2 that does not happen when using another deflate implementations such as zlib, so I think it is a miniz_oxide bug: rust-lang/flate2-rs#434
The text was updated successfully, but these errors were encountered: