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

[Steve Lhomme]

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.

I also think we may differentiate between the types to free, like 
libvlc_free_string(). But I think that's all we currently share to free.

>  >Not only that but delete
>> would bring rather interesting considerations with RTTI.
>>
>> If you want to abstract that away, you need case-specific release 
>> functions
>> like Romain pointed out - not libvlc_free().
> 
> It turns out that in many cases it would not be libvlc_free().
> 
>>> That would force every host app to embed a C++ runtime just because
>>> libvlc happens to be written in C++.
>>
>> That example is absurd. In general, just switching LibVLC to C++ 
>> breaks the
>> ABI. 
> 
> The extern "C" ABI remains the same, even if it's coded in C++ underneath.
> 
>  > Whether it requires the application to have a C++ runtime or not would
>> depend on the platform. In many cases, it actually would indeed need a 
>> C++
>> runtime regardless of libvlc_free().
> 
> Yes, running a C++ libvlc will require a C++ runtime. That doesn't mean 
> the libvlc host has to deal with it. Again, in Windows this is hidden 
> when loading the DLL (dunno how .so loading works). There is no reason 
> to force the host to call the C++ delete. Just like there is no reason 
> to force the host to call the C free().
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel