[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.


More information about the vlc-devel mailing list