// the find
redis/hiredis
Minimalistic C client for Redis >= 1.2
hiredis is the C client library for Redis — minimal RESP2/RESP3 protocol support wrapped in a printf-style command API, plus a standalone reply parser and separate sync/async APIs. It's for C/C++ developers who need a lightweight Redis client, or anyone writing a language binding on top of Redis (Ruby, Python, etc. clients often embed hiredis's parser).
The reply parser (redisReader) is decoupled from the socket I/O, so you can feed it bytes from any transport and get back redisReply structs — this is exactly why so many language bindings use hiredis internally instead of writing their own RESP parser. RESP3 support is thorough: doubles, booleans, maps, sets, bignum, verbatim strings, and PUSH messages are all modeled, with a sane default PUSH handler so RESP2 code doesn't break on upgrade. Event-loop adapters ship for libev, libevent, libuv, libhv, ae, Qt, glib, and more, each with a working example — hooking the async API into whatever loop you already run is low-effort. Allocator injection (hiredisSetAllocators) lets you swap in a custom allocator wholesale, which matters if you're embedding this in something memory-constrained.
Manual reply freeing is a real footgun: freeReplyObject semantics flip between the sync API (you call it) and async API (hiredis calls it for you), and the README itself has to call this out explicitly — mixing the two up corrupts memory. redisContext and redisAsyncContext are both documented as not thread-safe, so any multi-threaded consumer has to build its own locking or connection-per-thread scheme on top; there's nothing in the library to help. There's no cluster or sentinel awareness at all — no topology discovery, no redirect handling, no failover logic, so production use against a Redis Cluster means hand-rolling that layer or pulling in a separate library. It's also connection-per-context with no pooling primitive, so anything beyond a toy app needs an external pool wrapper.