[vlc-devel] [vlc-commits] Remove libvlc_free
Rémi Denis-Courmont
remi at remlab.net
Wed May 22 18:51:06 CEST 2019
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.
> 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/
More information about the vlc-devel
mailing list