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

[Rémi Denis-Courmont]

Calling it in the DLL is UB if the thread has no CRT or the wrong CRT. As stated like 7 times already 

Le 24 mai 2019 11:35:12 GMT+03:00, Steve Lhomme <robux4 at ycbcr.xyz> a écrit :
>On 2019-05-24 10:04, Rémi Denis-Courmont wrote:
>> If you don't have the right free inside the EXE, you cannot call
>LibVLC 
>
>I said you do the free *inside the DLL* in order to make it work.
>
>> 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é.
>> 
>> _______________________________________________
>> 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/cbf0bfb2/attachment.html>