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

[Steve Lhomme]

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
>