[vlc-devel] [PATCH 0/2] Libvlc formatted log callback

[Jeremy Vignelles]

Hi Rémi,

Thanks for your review.

> Le 18 mai 2019 à 09:18, Rémi Denis-Courmont <remi at remlab.net> a écrit :
> 
> 
> Le perjantaina 17. toukokuuta 2019, 11.04.59 EEST Jérémy VIGNELLES a écrit :
> > Hi,
> > 
> > In libvlc, there is currently a `libvlc_log_set` function, that can register
> > log callback in a vprintf style, that is, with a `va_list` argument.
> > 
> > This is nice when you are trying to call from C, but when using other
> > languages like C# or Java, va_list is impossible to get right, and even if
> > it did, those languages do not provide ways to format that kind of stuff.
> 
> We already tried to adapt to foreign function interfaces and failed, and 
> realized that the FFI just could not handle it across the broad set of 
> platforms that VLC supports.
> 
> Then we took the logical decision going forward: to reject that sort of 
> patchsets.


As of today, every libvlc API that made sense to expose are implemented in LibVLCSharp, with the only exception of that specific logging API. I don't know if there is something missing for other languages on specific APIs, but as far as .net is concerned, the other functions are correctly supported.

> To call LibVLC from .Net or Java, you need OS-specific, architecture-specific, 
> and windowing system-specific code anyway.


You are right, some platform-specific code needs to be run. That detection can happen at runtime.

> There is the library path, name, version


At runtime, we detect the platform we are running on and "guess" the library name and path to load. This is far from ideal, but can be overriden by configuration

> calling convention, name mangling


Is there more than one calling convention in VLC? We are using stdcall didn't run into any issue so far.

> and mapping of scalar types,


.net is perfectly able to map scalar types into what they call UInt32, Int8...
The only issue so far is that strings can be directly marshalled only as ASCII or UTF16. Things are changing, but for the set of platforms we are supporting, UTF8 needs to be manually marshalled.

> and mapping of compound types,


Structs are redeclared in C#, alignment can be handled too.

> mapping of unions,


This one is tricky, but doable

> window handles,


We can get them

> heap allocations,


Not sure what you mean

> etc. va_list is the least of problems


It's the only remaining

> and you don't even need to look into va_list here, only pass it forth.


I tried that but it turns out that it doesn't work well : 


* va_list is different for each platform, and marshalling it causes alignment issues
* Pass it forth where? That would assume we have a shared library that could *correctly* format that string. We can agree there: printf-like function on windows are not compliant with the standard. I suppose that this is why we have a vsnprintf reimplementation in VLC I guess...


> The best way to handle all those problems is in a native library. But if you prefer to do it the hard way directly in high level language, then that's your 
> problem.


I totally agree with that, va_list handling is quite impossible in .net at least.

> The train has left the station. This does not belong in LibVLC.


Either it belong to LibVLC, or it belongs to an external library like the one I linked, which needs to be build on all platforms (Windows, Linux, Mac, iOS, Android, multiplied by the number of different CPU archs). As VLC is already built on those platforms and already has a working vsnprintf implementation, I thought this was the right place to do it.

> -- 
> Rémi Denis-Courmont
> http://www.remlab.net/
> 
> 
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel