<html><head></head><body>If you don't have the right free inside the EXE, you cannot call LibVLC directly as already explained several times. So it's moot whether you have libvlc_free() or not.<br><br><div class="gmail_quote">Le 24 mai 2019 10:44:11 GMT+03:00, Steve Lhomme <robux4@ycbcr.xyz> 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">On 2019-05-24 9:36, Rémi Denis-Courmont wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">I don't know what point you are trying to make here. Nobody questioned <br>that mismatched heap allocators would crash. Of course they would.<br><br>The problem is that if you can't get the right free() function, then you <br>can't call libvlc_free().<br></blockquote><br>Yes, you can get the right free(), if the free() call is done inside the <br>DLL and not the EXE. It was possible before you removed libvlc_free(). <br>It was even documented as such.<br><br>Now this trivial use case is not even possible with current state of <br>libvlc. The host cannot reliably release the memory it is given.<br><br> At that point, the code is probably already UB<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">even before freeing the allocation either way.<br><br>Le 24 mai 2019 09:37:20 GMT+03:00, Steve Lhomme <robux4@ycbcr.xyz> a écrit :<br><br> On 2019-05-24 7:44, Steve Lhomme wrote:<br><br> On 2019-05-24 7:25, Steve Lhomme wrote:<br><br> On 2019-05-23 17:11, Rémi Denis-Courmont wrote:<br><br> Le torstaina 23. toukokuuta 2019, 13.57.32 EEST Steve<br> Lhomme a écrit :<br><br> Here's another one: we could decide to rewrite<br> libvlc in C++ and keep<br> the same ABI. Does that mean we would have to forced<br> libvlc hosts to<br> call "delete psz-str" because we don't feel like<br> keeping<br> libvlc_free() ?<br><br><br> You would have to keep using malloc() otherwise you<br> would break the<br> existing<br> ABI 3.0 or 4.0 anyway that says you can use free().<br><br><br> That's indeed a problem. I think the free() option should<br> not have<br> been there in the first place. I would rather vote to remove<br> this option.<br><br> For example we could decide that for performance reasons we<br> allocate<br> using aligned_alloc(). On some system that requires an<br> aligned_free().<br> We cannot do that if we allow free() of a particular runtime.<br><br><br> Another use case: building libvlc/vlc with allocation tooling,<br> redirecting malloc/free to debug leaks. Calling free() outside<br> of libvlc<br> with memory allocated this will likely crash or report errors<br> when a<br> legitimate free() is done. We should not tie our hands by allowing<br> free() at all.<br><br><br> Attached is a quick example of a library done incorrectly:<br><br> The EXE links with the *debug* DLL C runtime, as most people would use<br> while debugging their code.<br><br> The DLL links with the *standard* DLL C runtime, as a distributed DLL<br> would use.<br><br> Calling free() on the memory returned by the DLL crashes with a heap<br> allocation error. That doesn't happen is the free() is done in the DLL.<br><br><br>-- <br>Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser <br>ma brièveté.<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><br><br></blockquote><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>