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

[Rémi Denis-Courmont]

No. In general, 'extern "C"' won't suffice to preserve the ABI as a whole. It only ensures that the function uses the C calling convention and namespace.

If you run a LibVLC app with an STDC++ ABI that differs from that of dynamically linked VLC C++ plugins, it will crash even now on some platforms. The C++ runtime version is part of the ABI even if none of the function prototypes are C++.

Le 24 mai 2019 08:25:18 GMT+03:00, Steve Lhomme <robux4 at ycbcr.xyz> a écrit :
>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.
>
> >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().
>
>It turns out that in many cases it would not be 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. 
>
>The extern "C" ABI remains the same, even if it's coded in C++
>underneath.
>
>> 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().
>
>Yes, running a C++ libvlc will require a C++ runtime. That doesn't mean
>
>the libvlc host has to deal with it. Again, in Windows this is hidden 
>when loading the DLL (dunno how .so loading works). There is no reason 
>to force the host to call the C++ delete. Just like there is no reason 
>to force the host to call the C free().
>_______________________________________________
>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é.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20190524/ccac58fd/attachment.html>