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

Romain Vimont rom1v at videolabs.io
Wed May 22 19:24:29 CEST 2019

Le 22 mai 2019 18:51:06 GMT+02:00, "Rémi Denis-Courmont" <remi at remlab.net> a écrit :
>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
>does not.)
>> I don't understand how calling a function (libvlc_free()), which
>> 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
>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.

Why is it related to libvlc_free()? What happens if you call free() from another existing libvlc function?

>> Anyway, IMO providing a separate "delete function" seems better,
>> 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.

I don't understand.

>It's just far far easier to write a
>native wrapper library

I don't get it neither.

>vlc-devel mailing list
>To unsubscribe or modify your subscription options:

More information about the vlc-devel mailing list