[vlc-devel] [vlc-commits] Remove libvlc_free
Steve Lhomme
robux4 at ycbcr.xyz
Fri May 24 11:47:05 CEST 2019
On 2019-05-24 11:06, Rémi Denis-Courmont wrote:
> Calling it in the DLL is UB if the thread has no CRT or the wrong CRT.
> As stated like 7 times already
It does depend on the C runtime. On Windows they deprecated the single
thread one
(https://docs.microsoft.com/en-us/cpp/c-runtime-library/multithreaded-libraries-performance?view=vs-2015).
> 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.
I don't think a thread is tied by the language runtime that created it.
And I'm pretty sure the OS allocator is safe from being called by
different threads for the same memory. That leaves the runtime to call
this allocator from the C source. If the free() is called in the same
DLL as the malloc, so with the same runtime, it should be fine.
If it wasn't the case that means that all code loading a DLL compiled
with a specific runtime would have to use that same runtime. This is
clearly not the case on Windows and unlikely on Linux. I don't think
Linux has to be built with the Intel Compiler in order to use an Intel
compiled EXE or DLL.
> 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.
> Le 24 mai 2019 11:35:12 GMT+03:00, Steve Lhomme <robux4 at ycbcr.xyz> a écrit :
>
> On 2019-05-24 10:04, Rémi Denis-Courmont wrote:
>
> If you don't have the right free inside the EXE, you cannot call
> LibVLC
>
>
> I said you do the free *inside the DLL* in order to make it work.
>
> directly as already explained several times. So it's moot
> whether you
> have libvlc_free() or not.
>
> Le 24 mai 2019 10:44:11 GMT+03:00, Steve Lhomme
> <robux4 at ycbcr.xyz> a écrit :
>
> On 2019-05-24 9:36, Rémi Denis-Courmont wrote:
>
> I don't know what point you are trying to make here. Nobody
> questioned
> that mismatched heap allocators would crash. Of course they would.
>
> The problem is that if you can't get the right free() function,
> then you
> can't call libvlc_free().
>
>
> Yes, you can get the right free(), if the free() call is done
> inside the
> DLL and not the EXE. It was possible before you removed
> libvlc_free().
> It was even documented as such.
>
> Now this trivial use case is not even possible with current state of
> libvlc. The host cannot reliably release the memory it is given.
>
> At that point, the code is probably already UB
>
> even before freeing the allocation either way.
>
> Le 24 mai 2019 09:37:20 GMT+03:00, Steve Lhomme
> <robux4 at ycbcr.xyz> a écrit :
>
> On 2019-05-24 7:44, Steve Lhomme wrote:
>
> On 2019-05-24 7:25, Steve Lhomme wrote:
>
> On 2019-05-23 17:11, Rémi Denis-Courmont wrote:
>
> Le torstaina 23. toukokuuta 2019, 13.57.32 EEST Steve
> Lhomme a écrit :
>
> 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().
>
>
> That's indeed a problem. I think the free() option should
> not have
> been there in the first place. I would rather vote to remove
> this option.
>
> For example we could decide that for performance reasons we
> allocate
> using aligned_alloc(). On some system that requires an
> aligned_free().
> We cannot do that if we allow free() of a particular runtime.
>
>
> Another use case: building libvlc/vlc with allocation tooling,
> redirecting malloc/free to debug leaks. Calling free() outside
> of libvlc
> with memory allocated this will likely crash or report errors
> when a
> legitimate free() is done. We should not tie our hands by allowing
> free() at all.
>
>
> Attached is a quick example of a library done incorrectly:
>
> The EXE links with the *debug* DLL C runtime, as most people
> would use
> while debugging their code.
>
> The DLL links with the *standard* DLL C runtime, as a
> distributed DLL
> would use.
>
> Calling free() on the memory returned by the DLL crashes with a heap
> allocation error. That doesn't happen is the free() is done in
> the DLL.
>
>
> --
> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez
> excuser
> ma brièveté.
> ------------------------------------------------------------------------
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel
> ------------------------------------------------------------------------
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel
>
>
> --
> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez
> excuser
> ma brièveté.
> ------------------------------------------------------------------------
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel
>
> ------------------------------------------------------------------------
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel
>
>
> --
> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser
> ma brièveté.
>
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel
>
More information about the vlc-devel
mailing list