After reading through the comments, I think it is a good idea to sum things up:
== The issue ==
`libvlc_log_set` is a good API that can register log callbacks.
An application using libvlc is able to get log messages, format them, and either show them to the user, or write them to a file.
This is great when the application is written in C, or uses an intermediate layer written in C.
However, the current shape of the API makes it hard to call from languages calling libvlc through FFI, because of the va_list argument. For a language like C#, there is no easily-accessible vsnprintf equivalent on all platforms that supports all formatted string markers.
LibVLCSharp, the official libvlc binding for .net, is impacted by this issue because it can't offer a binding for libvlc_log_set to C# users.
== What can we do about it? ==
= Leave things as-is =
+ Keeps compatibility with existing apps
+ conforms to what is done in other libraries, like libavutil
+ does not add allocation overhead (No allocation means no malloc failure too)
- Requires higher-level languages to have a native glue code, built for each platform libvlc will be used on, which is a hard work for bindings like LibVLCSharp.
= Keep libvlc_log_set, but add a formatted log callback next to it =
+ Keeps compatibility
+ Adds ability to consume from other languages
- Might create confusion about which API to call
- libvlc_instance_t.log will need to keep track of the two forms of log callback, which I don't find really clean.
= Use the v2 of the patch : Remove libvlc_log_set and use a preformatted log callback instead =
+ Solves the issue, and makes the API easier to consume from any language using libvlc from FFI.
+ Keeps only one logging API
+ Allows to filter by log level before formatting the log.
- Breaks the libvlc logging API
= Introduce a libvlc_vsnprintf that can format log message the way libvlc expects? =
+ Cross-platfrom solution
+ Higher-level languages could probably pass the args as a pointer (not sure about this one, this will need to be checked)
+ Doesn't touch the libvlc_log_set API and let the user decide how things are formatted.
- Adds marshalling overhead
- The API has nothing to do with libvlc's main purpose.
Did I miss something? Has anyone other ideas/objections?
What's your preference everyone?