ERR_REPORTING_SYSLOG is never defined about libsrtp HOT 4 CLOSED

I've never tried it myself and wouldn't be surprised if it doesn't work. My involvement with maintaining libsrtp only goes back about a year. Maybe one of the other maintainers knows the history on this.

from libsrtp.

It looks like crypto/kernel/err.c will send errors to syslog if ERR_REPORTING_SYSLOG is defined. Whether this code works is anyone's guess. But there's no way to enable this through the configure script. Therefore, it appears --enable-syslog is useless. However, a downstream project could still enable ERR_REPORTING_SYSLOG using CFLAGS. My vote would be to remove the --enable-syslog option and leave the code in err.c "as is".

from libsrtp.

Facts:

• There is NO reason at all for a library to log into stdout/stderr.
• There is NO reason at all for a library to log into syslog.
• There is NO reason at all for a library to log into a file.

A library is a piece to be integrated into an application. The library must provide an API with descriptive error codes (and optionally string descriptions). libsrtp already does that. So the app is responsible for collecting those errors reported by the library and deciding whether to log them to stderr, to a file, to syslog or to send them via Whatsapp.

Please, remove everything related to "logging" from libsrtp.

PS: There is a single place in which a library MAY log something to stderr: The case in which it is about to abort due to an internal bug that should never happen. In that case it is "acceptable" for the library to print the error to stderr before calling abort(). This is for example the only case in which the very well designed libuv C library prints to stderr.

from libsrtp.

I've pushed two commits into the 2_0_0_dev branch today to resolve this. The syslog option is no longer present. The stdout option is retained, but now disabled by default. I've retained this since it's useful for troubleshooting.

from libsrtp.