
<html><head></head><body>Hi<br><br>It was never possible not to care about the C runtime. Calling LibVLC without a C runtime or with a mismatched one is and always was UB by design of the OS NDKs. Your delusions are not a design criteria, and I would appreciate if you refrained from posting incorrect information that may be misconstrued as guidance for LibVLC app developers.<br><br><div class="gmail_quote">Le 21 mai 2019 23:51:28 GMT+03:00, Jeremy Vignelles <jeremy.vignelles@dev3i.fr> a écrit :<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<pre class="k9mail">So, what did the technical comittee decided in this regard?<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">That means libvlc users in other languages have to make a call to the C <br>runtime by themselves ? Right now it was possible to just take the <br>libvlc DLL and never have to deal with C at all.<br></blockquote><br>Indeed, this is what have been done so far with LibVLCSharp for strings returned from libvlc and marked as "you must free them". Since .net does not have any implementation for freeing things from the native side.<br><br>One might argue that the module that does the allocation needs to free it. In other words, I find it quite logical that the memory allocated from libvlc returns to libvlc.<hr>vlc-devel mailing list<br>To unsubscribe or modify your subscription options:<br><a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a></pre></blockquote></div><br>-- <br>Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.</body></html>