liblogging-stdlog – code reviewers sought

I am looking for some code reviewers.

I have worked hard on liblogging-stdlog, which aims at becoming the new enhanced syslog() API call. The library is thread- and signal-safe and offers support for multiple log drivers, just like log4j does.

More elaborate description is here:


As the lib is becoming ready for prime time, I would really appreciate if some folks could have a look at the code and check for problems and/or offer suggestions in regard to the API.

It is only the code inside ./stdlog (roughly 1400 lines of code, including header files, empty lines and comments):

The man page is available here:

All feedback is very welcome!



where is liblogging heading to?

I just received a question whether or not I plan to change the build system for liblogging to a modern one, just like I have done with rsyslog recently.

As a reminder, liblogging is the library that provides RFC 3195 functionality to rsyslog. Of course, others can integrate it too. Writing liblogging was a considerable effort. When I did this, I had hoped that RFC 3195 would become much more dominant in the logging space. Unfortunately, the current version became a failure. This is also one reason that rsyslog supports receiving messages via 3195 but not sending them – the interest was too low (to phrase it politely) and other features received priority.

Liblogging development is currently “on hold”. I was tempted to completely abandon it, but then Cisco moved RFC 3195 support into IOS. That was one thing that made me hope that the standard may become accepted in the long term. Recently, while designing rsyslog v3, I noticed that rfc 3195 (or more precisely BEEP, RFC 3080) indeed offers a very good choice for protocol extensions. I am currently very seriously thinking about re-vitalizing liblogging and make it the foundation of rsyslog-to-rsyslog communication.

But there are also a number of other subtleties. Most importantly, the current RFC 3195 is insufficient for practical purposes. For example, it limits message size to 1K. It also does not support new syslog headers. The IETF is considering a new version of 3195, which will fix these shortcomings. Of course, I can go ahead and use from 3195 what makes sense to me and extend the rest on my own. But that will cause trouble in the long term and I do not really like that.

There are also some funding issues. As you possibly know, we fund our projects also via closed-source Windows software (e.g. MonitorWare Agent or EventReporter). The current liblogging has a BSD-style license. That was chosen in the hope it will help to make it a standard. However, it also enables our closed-source competitors to pull our work without contributing anything back.

So, to be honest, if we go ahead and do a new substantial effort on liblogging, we will probably release it under GPLv3. That enables everybody who does open source to use it, but prohibits our closed-source competitor to integrate the library. Of course, we need to retain the right to use it ourselfs in our commercial products, but I think it can be arranged in a way that is compatible with GPLv3 – at least I have seen a number of projects doing that.

To summarize in short words: liblogging is currently on hold and will be for at least some more weeks. We are deciding if we extend it. If so, that will go along with rsyslog development.