Why I Fell in Love with This Logging Library
To be honest, when I first started with C language, debugging was my biggest headache. The screen was filled with printf statements; I was afraid to delete them, yet they made everything a mess. Later, while browsing GitHub, I discovered log.c, and after trying it out, I was utterly amazed. This tool acts like a helpful assistant, organizing chaotic logs clearly. Now that I lead a team on embedded projects, my first requirement is to use this library.
I remember working on a smart home gateway project last year, still trying to pinpoint a memory leak issue at 2 AM. If it weren’t for the trace-level logs from log.c helping me identify the exact line of code, I would have probably had to work all night. Since then, I’ve been recommending this library to everyone; it has truly been my lifesaver.
How to Use It
Simply put, you just need to throw the log.c and log.h files into your project and compile them with your code. It provides six log levels, from trace to fatal, and works just like printf:
log_debug("User %d logged in successfully", user_id);
log_error("Database connection failed, error code: %d", err_code);The output to the console looks like this:
20:18:26 TRACE src/main.c:11: Initializing module
20:18:27 DEBUG src/auth.c:34: User 123 attempting to log inWhat I love most is its color display feature. By adding the -DLOG_USE_COLOR parameter during compilation, different log levels are displayed in different colors, making it easy to spot error messages.
This is How I Use It in Real Projects
In our IoT gateway project, I configured it like this:
// Record everything during development
log_set_level(LOG_TRACE);
// In production, only record warnings and errors
log_set_level(LOG_WARN);
// Output logs to a file as well
FILE *fp = fopen("/var/log/gateway.log", "a");
log_add_fp(fp, LOG_INFO);One pitfall to note: remember to set the lock function in a multithreaded environment, or the log output will get messy. Our project faced this issue, and we resolved it by adding log_set_lock.
Advanced Features That Impress
Besides basic functionality, log.c also supports callback functions. This means you can send logs to a network, database, or your own monitoring system. In our project, we wrote a callback to push error logs in real-time to WeChat:
void wechat_callback(log_Event *ev) {
char buf[1024];
vsnprintf(buf, sizeof(buf), ev->fmt, ev->ap);
// Call WeChat API to send message
}
log_add_callback(wechat_callback, NULL, LOG_ERROR);Honestly, I initially thought this callback feature was somewhat unnecessary, but later I found it incredibly useful. Especially for operational monitoring, receiving error messages directly on my phone means I no longer have to constantly watch log files.
Comparing with Other Logging Libraries
The biggest advantage of log.c is its lightweight nature; the entire library consists of just two files and a few hundred lines of code. Unlike the cumbersome log4c, which can be a nightmare to configure. However, it is true that it has relatively simple functionality, lacking log rotation and complex filtering rules. But for 90% of projects, it is more than sufficient.
I now have a rule for my team: if you can use log.c, don’t use something more complex; keeping the code simple is key. Unless you’re building an enterprise-level distributed system, then it’s a different story.
Final Thoughts
After using log.c for so many years, my biggest takeaway is that a good tool isn’t about how complex its features are, but how easy it is to use. This library is like a Swiss Army knife: compact yet practical. Especially in resource-constrained embedded environments, its low memory usage has been a huge help.
If you’re struggling with log management in your C projects, I highly recommend you try log.c. It’s open-source and free, so the cost of trial and error is zero. If you don’t like it, you can always switch, but I bet you’ll fall in love with it.
Project address: https://github.com/rxi/log.c