Frommi

I think it would be okay, the important part is to preserve ABI and error model. Well, the compressor struct as well as mz_stream are already changed. It is okay...

Hi. Sorry for the delayed reply. Your `State` is cleaner than what we have now, I really like it. I think there is a place for the safe wrapper that...

Okay, I read the code and I think that you are onto something. There are two things that stand out for me: - The need for two functions `get` and...

The point about the `?` operator is very good. I now think that your first approach with API is best and I can't see ways to improve it. I thought...

It's okay, I am mostly free on the weekends. Most of the work is already done anyway.

Hi! 1) `FailedCannotMakeProgress` means there is no way input data is valid (pending any bugs). Calling `decompress` again will continue to yield this error until `init` is called. `NeedsMoreInput` means...

>Is miniz_oxide supposed to be able to handle data that is truncated at an arbitrary place? Yes, it is able to handle input even byte-by-byte. I completely forgot about that....

Output buffer that is given to `decompress` should have the old decompressed output data to do the matches. It must span at least `TINFL_LZ_DICT_SIZE` back or the amount of already...

That got me thinking that we really don't need rusty API, because flate2 will be better at it anyway. So, the [weird manipulation](https://github.com/Frommi/miniz_oxide/blob/b0d916d2c694494dc55e10d5856aa8ca3b815d32/src/tdef/mod.rs#L176) of callbacks at least isn't exposed outwards....

I faced the same issue when I was writing fuzzing: I solved the problem using objcopy, adding prefix c_ to every symbol in one version of miniz. See: https://github.com/Frommi/miniz_oxide/blob/master/build_fuzz.sh