Skip to content

Conversation

@brian-pane
Copy link

No description provided.

@codecov
Copy link

codecov bot commented Apr 21, 2025

Codecov Report

Attention: Patch coverage is 76.40000% with 59 lines in your changes missing coverage. Please review.

Files with missing lines Patch % Lines
libz-rs-sys/src/gz.rs 76.40% 59 Missing ⚠️
Flag Coverage Δ
fuzz-compress ?
fuzz-decompress ?
test-aarch64-apple-darwin 89.24% <76.40%> (-0.33%) ⬇️
test-x86_64-apple-darwin 87.23% <70.00%> (-0.38%) ⬇️
test-x86_64-unknown-linux-gnu 90.44% <70.00%> (+0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines Coverage Δ
libz-rs-sys/src/gz.rs 91.13% <76.40%> (-2.40%) ⬇️

... and 7 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@brian-pane brian-pane force-pushed the gzwrite branch 3 times, most recently from b3d241a to f9a0bf2 Compare April 21, 2025 01:20
return Err(());
};
state.input = input.as_ptr();
// Note: zlib-ng fills the input buffer with zeroes here, but it's unneeded.
Copy link
Member

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?

Copy link
Author

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.

Copy link
Member

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.

// Directly compress user buffer to file.
state.stream.next_in = buf.cast::<_>();
loop {
let n = cmp::min(len, c_uint::MAX);
Copy link
Member

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.

Copy link
Author

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.

Copy link
Member

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.

Copy link
Member

@folkertdev folkertdev left a 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";
Copy link
Member

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.

@folkertdev folkertdev merged commit 2caca49 into trifectatechfoundation:main Apr 21, 2025
24 checks passed
@brian-pane brian-pane deleted the gzwrite branch April 22, 2025 15:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants