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

[Rémi Denis-Courmont]

Le torstaina 23. toukokuuta 2019, 13.57.32 EEST Steve Lhomme a écrit :
> > 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().
> Given it's trivial and equivalent, that's not a case that matters.

That case does not matter. And since it's the only case that actually works, 
libvlc_free() does not matter. Yes.

> > 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.
> 
> It becomes UB/confusing if you force the host app to use the free() of a
> certain runtime (that you have to find out and match by yourself).

From the get-go, if you mix multiple runtimes of the same language, it will be 
confusing, if it works at all.

> It is not confusing if libvlc_free() does it for you.

And by what magic it will achieve that? Say the calling thread has no C 
runtime, e.g. it was created CreateThread() instead of _beingthread(ex)() - or 
clone() instead of pthread_create(). Now it's UB to call CRT functions from 
that thread. free() is UB, yes. libvlc_free() too.

The difference is that you'll be hard-pressed to incorrectly call free() 
because, in all likelihood, it would fail safely at build time or at least as 
load time. libvlc_free() though will link happily, and then UB. And that's 
worse.

(...)
> You still haven't presented a case where it solves a problem to call
> free() directly while we have shown that in many cases it's a bad choice.

There are no cases where you can call free() and cannot call libvlc_free(). 
The point is that there are also no cases where you can safely call 
libvlc_free() but not free(). The mere fact that libvlc_free() exists is 
misleading app developers.

> Maybe someone in the past thought it was a bad idea to have libvlc_free,
> maybe. But you are the only one making that claim now, against many
> people who presented counter arguments.

Rather I have seen zero counter-arguments and plenty of people ignoring or 
explicitly ignoring mine.

> Here's another one: we could decide to rewrite libvlc in C++ and keep
> the same ABI. Does that mean we would have to forced libvlc hosts to
> call "delete psz-str" because we don't feel like keeping libvlc_free() ?

You would have to keep using malloc() otherwise you would break the existing 
ABI 3.0 or 4.0 anyway that says you can use free(). Not only that but delete 
would bring rather interesting considerations with RTTI.

If you want to abstract that away, you need case-specific release functions 
like Romain pointed out - not libvlc_free().

> That would force every host app to embed a C++ runtime just because
> libvlc happens to be written in C++.

That example is absurd. In general, just switching LibVLC to C++ breaks the 
ABI. Whether it requires the application to have a C++ runtime or not would 
depend on the platform. In many cases, it actually would indeed need a C++ 
runtime regardless of libvlc_free().
 
-- 
レミ・デニ-クールモン
http://www.remlab.net/
.