Re: High-priority library replacements?

[Isaac Dunham <idunham@lavabit.com>]

On Thu, 25 Apr 2013 00:15:53 -0400
Rich Felker <dalias@aerifal.cx> wrote:

> 3. Image format and compression (libpng, zlib, etc.). The existing
> libraries are full of atrociously bad error-handling practices, and
> quite bloated. These libraries should be well-factored so that
> programs that just want to read (the majority of use cases) don't have
> to pull in code for writing. Unfortunately the interfaces might not be
> so simple, since an important usage case is progressive rendering of
> partially-loaded images, both for the purpose of loading over slow
> network connections and for rendering thumbnails quickly.

Have you perchance seen libpnglite?
http://sourceforge.net/projects/pnglite/files/

Yes, I know it's NOT well-factored; the author wanted something where
a single file and header could be added to a project and there's PNG support.
Uses the png_ namespace.
AFAICT, it accepts either a buffer to use for the png or a null pointer, in which case it malloc's what is necessary. 
License is BSD-ish.
It includes a reference to "zlite.h", which seems to be a zip library with a z_ namespace.

Also, I ran across stb_image_write.h, but...I hesitate to _recommend_ something where the header contains all the function source. stb_image.c is another "small, but I don't think that's good enough" thing... 

> All of these libraries should:
> 
> - Avoid namespace pollution. Only external symbols should be the
>   public API and internal-use stuff prefixed with an ugly prefix
>   that's extremely unlikely to clash with anything.
> - Avoid unnecessary allocation. Use caller-provided objects where
>   possible or provide both options.
> - Have absolutely zero global state.
> 
> That's all I can think of at the moment but I'm sure there are other
> needs I've come across and forgotten. Please feel free to supplement
> this list.

A links that may be helpful, perhaps...
http://bashismal.blogspot.com/2011/10/unbloated-resources-in-c.html

-- 
Isaac Dunham <idunham@lavabit.com>