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

[Rémi Denis-Courmont]

A binary interface is everything from calling convention to unprivileged CPU state, to what you can or cannot load/do in the same process. Change any of those and you potentially break compatibility of the binary interface.

Le 24 mai 2019 11:50:28 GMT+03:00, Steve Lhomme <robux4 at ycbcr.xyz> a écrit :
>On 2019-05-24 10:02, Rémi Denis-Courmont wrote:
>> 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.
>
>What else is there in an ABI ?
>
>> If you run a LibVLC app with an STDC++ ABI that differs from that of 
>
>I was talking specifically about the same ABI whether it's coded in C
>or 
>C++ (or whatever language than can handle the C calling convention).
>
>> 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++.
>
>In a C++ ABI yes, but that's what I'm talking about.
>
>> 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é.
>> 
>> _______________________________________________
>> 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é.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20190524/f556bacd/attachment-0001.html>