[Mankaninen]

With respect to the bmp example: 1. Removing the bmp_get implies that the application needs to implement a shadow image if it needs to check the color o a certain pixel. Or even worse, take a direct peek in its void memory area. 2. void pointers instead of bmp_pointers makes it easier to create a mess, the compiler will not tell you that you called the bmp library with a pointer to a jpg memory area. 3. Not doing range checking in the library - but imposing that burden on the caller - is a bad practice. If the caller does the same - expects his caller to do the checking - we end up with a sequrity risk.

Trying to minimize the library by pushing work to the application is wrong every time you expect the library to be used more than once. Despite these objections, I like libraries that are free of IO and mallocs!

[spc476]

When I fell down into the rabbit hole of DNS, I wrote code to just encode and decode DNS packets [1]. All the existing libraries [2] had a complex API that provided a separate function for querying a few record types (A, AAAA, MX, TXT, SRV, maybe NS and SOA), leaving the rest unimplemented. They also tend to have complex network architectures to handle retries, caching, and parallel queries which could be hard to integrate into a project that had an existing network framework.

Mine? Just two functions: dns_encode() and dns_decode(). No I/O. No malloc().

[1] https://github.com/spc476/SPCDNS

[2] The ones I was looking at are written in C.

[lifthrasiir]

> No malloc().

...by having your own arena allocator! I do agree that it is quite doable in this particular case, but I always remember that a custom memory allocator of OpenSSL made Heartbleed much more devastating.

[spc476]

... of memory passed in by the user! So it's up to the caller to make sure memory contains unclassified information.

[kristianp]

Yes, this made me want to reach for a safer language, I could see the potential buffer overflows loud and clear:

    void          bmp_init(void *, long width, long height);

[DougBTX]

The corollary of "no error handling" is "caller must be perfect", it is the opposite to defensive coding. I can see the appeal, it puts minimal constraints on the caller, in a sense making the library functions as flexible as possible, but exposing an API so easy to misuse seems reckless, even if the API is elegant in its own way.