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

[Steve Lhomme]

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
>