[vlc-devel] [vlc-commits] Remove libvlc_free

[Rémi Denis-Courmont]

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.

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

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20190524/8aaef53a/attachment.html>