-
-
Notifications
You must be signed in to change notification settings - Fork 29
Implement gzwrite and gzflush #347
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
Conversation
Codecov ReportAttention: Patch coverage is
Flags with carried forward coverage won't be shown. Click here to find out more.
... and 7 files with indirect coverage changes 🚀 New features to boost your workflow:
|
b3d241a to
f9a0bf2
Compare
| return Err(()); | ||
| }; | ||
| state.input = input.as_ptr(); | ||
| // Note: zlib-ng fills the input buffer with zeroes here, but it's unneeded. |
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.
Are you sure there won't be any issues with reading uninitialized memory?
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.
The gz code only reads parts of input that have been written (confirmed by Miri). As long as the inflate and deflate code don't read past the filled part of input, we won't need to zero out the memory.
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.
They won't read past the range that you give it. assuming you don't give it uninitialized input bytes we should be good then.
libz-rs-sys/src/gz.rs
Outdated
| // Directly compress user buffer to file. | ||
| state.stream.next_in = buf.cast::<_>(); | ||
| loop { | ||
| let n = cmp::min(len, c_uint::MAX); |
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.
This seems kind of pointless? In the original code, len is a size_t, which I think can be 64-bit when c_uint is only 32-bit.
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.
I'll change the len parameter in this function to usize for consistency with the size_t in the original, which will make this check relevant.
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.
Actually when len is a usize this operation is actually meaningful.
folkertdev
left a comment
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.
LGTM then
|
|
||
| // Check that the requested number of bytes can be represented by the return type. | ||
| if c_int::try_from(len).is_err() { | ||
| const MSG: &str = "request does not fit in an int"; |
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.
just as a note, const MSG: &str = "some literal" is the same as let msg = "some literal". String literals always get a static lifetime and are stored in the directly in the binary, just like constants.
No description provided.