Maybe I'm getting old, but libabc's README comes across as unprofessional and more than a little sloppy. I also disagree with some particular points made in this README:
> Make your library threads-aware, but *not* thread-safe!
This piece of advice is confusing. I think the author meant to make libraries thread-agnostic: don't bend over backwards to accommodate access to the same data from multiple threads, but don't unnecessarily couple different pieces of data either.
> avoid hidden fork()/exec() in libraries
Great advice. We can just use posix_spawn instead: err, wait. How do I call this function under Linux? The author also should be more specific about pthread_atfork's alleged brokenness.
> You must place #ifndef libabc, #define libabc, #endif in your header files. There is no other way.
Actually, there is a better way: #pragma once (http://en.wikipedia.org/wiki/Pragma_once). It's shorter than traditional header guards (one line versus three), and it eliminates the risk of name collisions. #pragma once is nonstandard, but it's supported by every compiler that matters.
> executing out-of-process tools and parsing their output is not acceptable in libraries. Ever.
I strongly disagree with this statement. Doing work out-of-process gives robustness (and sometimes security) guarantees that are just not possible with calls into libraries. The world would be a better place if PAM, for example, did authentication separately. (I once had to debug a nasty file descriptor leak in pam_krb5 that wouldn't have been an issue had the PAM work been some in an ephemeral context.)
> separate 'mechanism' from 'policy'
I don't think this phrase means what the author thinks it means.