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

[Steve Lhomme]

On 2019-05-22 18:51, Rémi Denis-Courmont wrote:
> Le keskiviikkona 22. toukokuuta 2019, 18.30.19 EEST Romain Vimont a écrit :
>> On Wed, May 22, 2019 at 06:25:14PM +0300, Rémi Denis-Courmont wrote:
>>> Le keskiviikkona 22. toukokuuta 2019, 11.44.11 EEST Thomas Guillem a écrit
> :
>>>>   I don't really care about UB,
>>>
>>> Then don't design an API for a language subject to UB.
>>
>> Could you or Thomas explain to me what is undefined behavior here?
> 
> I can't speak for Thomas, and I was refering to the fact that is afflicted by UB
> in general. (Not all languages have UB. For instance, single-threaded Java
> does not.)
> 
>> I don't understand how calling a function (libvlc_free()), which happens
>> to just call free(), is undefined behavior.
> 
> In the trivial/normal case, all threads in the process are initialized for the
> same C run-time, and libvlc_free() is just a useless indirection to free().

Given it's trivial and equivalent, that's not a case that matters.

> UB can occur if there are more than one C run-time in a process though, or if
> you use LibVLC on a non-C/C++ thread.

It becomes UB/confusing if you force the host app to use the free() of a 
certain runtime (that you have to find out and match by yourself). It is 
not confusing if libvlc_free() does it for you.

I already explained that on Windows it's possible (and actually common) 
to mix C runtime between libraries. There are certain rules to apply 
between DLLs using different runtime. One of them is that you cannot 
release memory allocated by a DLL outside of the DLL. That seems like a 
trivial rule that we already enforce for every other thing we allocate 
in libvlc. And that's not even considering the fact other languages may 
not be able to call free() at all.

You still haven't presented a case where it solves a problem to call 
free() directly while we have shown that in many cases it's a bad choice.

Maybe someone in the past thought it was a bad idea to have libvlc_free, 
maybe. But you are the only one making that claim now, against many 
people who presented counter arguments.

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() ? 
That would force every host app to embed a C++ runtime just because 
libvlc happens to be written in C++.

>> Anyway, IMO providing a separate "delete function" seems better, because
>> in the future we may need to destroy additional internal resources.
> 
> Yes - we already do that for non-trivial object types.
> 
> But as far as running CIL code is concerned, this is far from sufficient to
> address C run-time concerns. It's just far far easier to write a dedicated
> native wrapper library that only exposes CIL-supported types, mainly fixed-size
> fixed-signedness integers, arrays of integers and opaque pointers.
> 
> -- 
> 雷米‧德尼-库尔蒙
> http://www.remlab.net/
> 
> 
> 
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel
>