How is this library a "mini" gzip decoder if it comes with functions to do things like write PNG files??
It's a nice effort, and sharing is appreciated, but that is most definitely not mini. It only seems that way because all the major libraries don't even pretend to care about code size and are bloated beasts.
This is mini: inflate algorithm in under 8KiB of code, gzip parser built on that in under 2KiB of code. Sans boilerplate, less than 400 LoC. Can also work entirely in-memory. Small enough that you don't even need to compile it into an object file.
That's a good point. The thing is that I've used a ready-to-use GZIP library (miniz) for building my API on top of it. I agree some parts of miniz are not necessary. I will put a note in my repo to point out your links.
Sorry if I come off a bit crass. What you have is still a major improvement over people dumping all of projects like zlib and libpng in just to load in files.
It's just that code complexity is probably my biggest pet peeve in programming. People often underestimate what a boon it is to avoid library dependencies. I've had so many code contributions from Windows people because all it takes to build any of my software is: "run the TDM/GCC installer, then run mingw32-make" ... the Linux/BSD mindset of "just apt-get/pkg install the dev library" doesn't work on the platform that most users and developers are on, sadly.
Whereas even I usually give up trying to build OSS that has a Windows port with a dozen dependencies.
So keep up the good work, and don't be afraid to gut some of those excess, unused functions in your own project :D
No worries. I like a direct feedback I get from HN readers and don't take it personally.
Honestly I haven't analyzed miniz in detail: I found it was one of the choices, so I looked around and used it.
Keeping stuff simple is very important, and it's unclear to me why they introduced anything with PNGs there. I may indeed decide to clean/replace it with something simpler.
I'm sure this is fine, but oh man, it looks sketchy.