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

[Romain Vimont]

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
>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().
>
>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,
>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.

I don't understand.

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

I don't get it neither.

>-- 
>雷米‧德尼-库尔蒙
>http://www.remlab.net/
>
>
>
>_______________________________________________
>vlc-devel mailing list
>To unsubscribe or modify your subscription options:
>https://mailman.videolan.org/listinfo/vlc-devel