Partial implementation of gzopen and gzclose

[brian-pane]

This includes skeletal implementations of the functions, plus build support (wrapped in a new feature flag called "gz") and test scaffolding.

[brian-pane]

With this PR, gzopen only opens the file and doesn't yet do any of the other required processing, such as verifying the magic number and reading the file header. I tried to keep the PR simple, to focus on the organization of the code and to make it easier to review. If it looks good, I'll iterate on the remaining functionality in future PRs.

[folkertdev]

overall this is solid, I've left a bunch of inline comments.

Currently the new files are not tested on CI (for clippy, formatting, and actually running the tests). That means the gz flag has to be enabled for instance here https://github.com/trifectatechfoundation/zlib-rs/blob/main/.github/workflows/checks.yaml#L156

[brian-pane]

I think the wasm32 run is failing when the gz open_close test case tries to open a file under $CARGO_MANIFEST_DIR/src/test-data. Is that path available in the wasm32 test environment? I was able to run the test locally using wasmtime --dir {absolute path to the CARGO_MANIFEST_DIR} but I don't know how the real CI environment works.

[folkertdev]

I fixed the wasm CI issue by explicitly passing the path. I've also opened bytecodealliance/wasmtime#10490 because the behavior of --dir with non-absolute paths is confusing.

I've also made sure that the prefix macro is not publicly exported (how to do that is not clear at all, but something I've come across before).

[brian-pane]

I suspect the failure on x86_64-pc-windows-gnu might be because I'm using the Allocator allocate/deallocate interface wrong, but I don't have a way to repro it.

[folkertdev]

I suspect the problem is strncpy not appending a NULL. You can printf the state.path and see that it's not right.

ugh nevermind C ...

[folkertdev]

I'll just try debugging on CI a bit. On linux all is well (at least, valgrind reports nothing), so yeah I'm not sure what's up.

[folkertdev]

Allright, got it. We were making some assumptions about alignment, which my new code for zeroed allocations violated. I also fixed some other issues with clippy and dropping CString values prematurely in the tests.

[brian-pane]

The three failed CI checks are all due to an external issue:

This is a scheduled Ubuntu 20.04 brownout. Ubuntu 20.04 LTS runner will be removed on 2025-04-15. For more details, see actions/runner-images#11101

[folkertdev]

allright, I think this should be a solid foundation now. I fixed that CI issue, and also added some extra docs to gzclose. In general we should, when the functions are complete, basically match the zlib docs (the idea being: users of our library should not have to read the official zlib docs; ours have all of the information too).