-
Notifications
You must be signed in to change notification settings - Fork 1
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
Fixed: Incorrect ZStandard API Usage for Partial Decompression of Blocks #13
Conversation
Changes the code to correct the error handling for: ZSTD_decompressStream While the original code is correct, for the cases of decompressing entire blocks; it's not valid for the case of partial decompression; because the result of ZSTD_decompressStream can return a non-error positive value that's used as a 'hint' for the next call to `ZSTD_decompressStream`. Previously we checked the result against 0, which is only true if the entire input has been decompressed; but in the case of partial decompression, this cannot be true.
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.
Nice catch, makes sense
Is this ready to merge then? |
Yeah this can be merged, I can do the unit test that catches this in another PR. (I'm writing said test right now) |
This probably fixes Which I couldn't originally reproduce. |
Codecov ReportAttention:
... and 1 file with indirect coverage changes 📢 Thoughts on this report? Let us know!. |
Changes the code to correct the error handling for:
ZSTD_decompressStream
in rare case of partial block decompression.While the original code is correct, for the cases of decompressing entire blocks; it's not valid for the case of partial decompression; because the result of
ZSTD_decompressStream
can return a non-error positive value that's used as a 'hint' for the next call toZSTD_decompressStream
.Previously we checked the result against 0, which is only true if the entire input has been decompressed; but in the case of partial decompression, this cannot be true.
Some Background Info
This is actually caused by an oversight during optimization, not a bug.
Originally during development it used to not be possible to partial decompress chunks; so the original code was not an issue.
However down the road, I added the
canFastDecompress
optimization toExtractBlock
for extracting files which start at offset 0 and only have 1 output. Originally this was intended as a hot path for chunked file blocks; however due to the constraints, this optimization was also valid for first item in SOLID blocks.In that specific edge case, partial decompression of blocks was now possible, and the existing code using the ZStandard API did not handle it correctly. (The existing code was correct, just not for partial extraction)
After merging, create release
0.3.7
(only need to push tag) and update the NuGet package in following PR