Expose crc32

[Opioid]

Exposing mz_crc32_oxide() could be useful for writing a PNG encoder/decoder that uses miniz_oxide for zlib compression anyway.

I can see that it is part of miniz_oxide/src/lib.rs, but not of miniz_oxide/miniz_oxide/src/lib.rs. But I don't understand what the difference is, only that I could not access mz_crc32_oxide().

On a related note, how can you access the streaming decompression that is discussed in issue 24?

[oyvindln]

That function is mainly there for the C api (which is the root folder) that mimicks the miniz C api. It's just a wrapper over the relevant functions in the crc library, so one may as well use that directly. the miniz_oxide subfolder is the actual miniz_oxide library. The C api is mainly used as an for an easy swap-in back-end for the flate2 crate. I wouldn't really recommend using it in a rust project otherwise as it's full of unsafe c exported functions.

CRC is only used for the gzip metadata, which tacks on to the start and end of the deflate-compressed stream. It's not used in the core miniz_oxide crate at all, that's really up to the front-end.

Generally I would suggest using flate2 with the rust back-end, which uses this library, as that has a nice streaming front-end. Going low level is only really needed if you need some special tight control of parameters like in the oxipng PNG optimizer.

As for the streaming decompression, still haven't gotten around to documenting it well. There is a brief overview in the issue and the linked project. I'll open a separate issue for that.

[oyvindln]

The distinction is between the C API (root folder) and the underlying miniz_oxide decompression library. The mz_crc32_oxide() is only there to replicate the miniz C api and is not used for decompression itself. The CRC checksup is only used in the gzip metadata header and trailers. It's only a thin wrapper around a crc library, so one might as well use one of the available crc libraries themselves if needed.

The C API was mainly to ease creating a drop-in replacement for miniz/zlib in the flate2 crate which provides an easy to use front-end for decompression, including streaming.

And yeah, still need to write some documentation showing the use of the core decompression function. There is some info in that issue, and in the linked repository in the meantime. Granted, I would recommend using the reader/writers in flate2 unless you have some special low-level needs.

[Opioid]

Thanks for pointing out the linked project!

I used miniz in some C++ projects and like that it is so small. I'm still considering flate2, but don't see a compelling reason to use it at the moment.
On the contrary I started thinking that it might be cool, if miniz_oxide had a feature where you could disable all the things that apparently only exist for flate2. Is that possible at all? (At least it is my understanding from your explanantion, that only the miniz_oxide subfolder is needed.)

Regarding crc32: adler is also exposed, so why stop there? If crc32 is included for the benefit of flate2, why shouldn't other users of the library have easy access, as they are also "paying" for the additional dependency?

I think it would be cool if miniz_oxide could be both the backend for flate2, but at the same time a maximally compact deflate implementation, in the spirit of miniz.

[Shnatsel]

miniz_oxide uses the crc32fast crate since e8d2a58, so you will get the exact same thing (and exact same dependency list) if you simply use that crate directly.

[oyvindln]

Closing this. As stated, one may as well use the library used, and it's only used in the C api anyhow.

On the contrary I started thinking that it might be cool, if miniz_oxide had a feature where you could disable all the things that apparently only exist for flate2. Is that possible at all? (At least it is my understanding from your explanantion, that only the miniz_oxide subfolder is needed.)

Yeah only the miniz_oxide subfolder is needed. The rest is the C API analogue. Though, if one uses that one would need to handle the gzip header manually, e.g with the gzip-header crate.

[Opioid]

miniz_oxide uses the crc32fast crate since e8d2a58, so you will get the exact same thing (and exact same dependency list) if you simply use that crate directly.

Until miniz_oxide switches to another crate.

Yeah only the miniz_oxide subfolder is needed. The rest is the C API analogue. Though, if one uses that one would need to handle the gzip header manually, e.g with the gzip-header crate.

Or just do it manually.