[vlc-devel] [vlc-commits] Remove libvlc_free
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
>> 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
>> > > 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
>> 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
>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,
>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
>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