oyvindln

I've now used the workaround and using cbindgen-exported headers, and as of d235075a20b9c43f7a8187eab443d0221e272fc6 miniz C and C++ test stuff compiles with it. Not yet sure if the compress/decompress structs should...

Hm, that doesn't seem entirely optimal, there ought to be a cleaner way to ensure this. I'm not entirely sure whether that specific behavior was intentional and the idea was...

Totally forgot to reply again.. Yeah it's supposed to stay low level, leaving writer/reader and stuff to flate2. I'm not sure what the best way to design a proper API...

Ok, after some digging it [looks](https://zlib.net/manual.html#Basic) the current behaviour may be what zlib does for the corresponding deflate call (I presume C miniz would behave the same as it's supposed...

Hoping we can look into this again, the current rust API is a bit inconsistent and was quickly cobbled together to provide a basis for a C API mirroring miniz....

```compress_to_vec_zlib``` is not a binding to zlib, zlib here refers to the output having a zlib header/footer as noted in the function description. The compression ratio shouldn't be significantly different...

It looks like using flate2 with the original C miniz gives the same result, while the zlib (library) back-end for flate2 and [deflate-rs](https://github.com/image-rs/deflate-rs/tree/dev) gives a similar result to the zlib...

To expand on this, currently miniz_oxide (and miniz) decides whether to use static or dynamic huffman codes simply based on whether the number of lz-compressed bytes (i.e number of literals...

Not sure, will have to look into it, some of these flags are remnants from porting miniz from C.

Yup. I am looking for suggestions for a V2 low-level API, as the current one is just some glue code we used to transition the flate2 backend from calling via...