<html><head></head><body>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.<br><br><div class="gmail_quote">Le 24 mai 2019 11:50:28 GMT+03:00, Steve Lhomme <robux4@ycbcr.xyz> a écrit :<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">On 2019-05-24 10:02, Rémi Denis-Courmont wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">No. In general, 'extern "C"' won't suffice to preserve the ABI as a <br>whole. It only ensures that the function uses the C calling convention <br>and namespace.<br></blockquote><br>What else is there in an ABI ?<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">If you run a LibVLC app with an STDC++ ABI that differs from that of <br></blockquote><br>I was talking specifically about the same ABI whether it's coded in C or <br>C++ (or whatever language than can handle the C calling convention).<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">dynamically linked VLC C++ plugins, it will crash even now on some <br>platforms. The C++ runtime version is part of the ABI even if none of <br>the function prototypes are C++.<br></blockquote><br>In a C++ ABI yes, but that's what I'm talking about.<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">Le 24 mai 2019 08:25:18 GMT+03:00, Steve Lhomme <robux4@ycbcr.xyz> a écrit :<br><br>    On 2019-05-23 17:11, Rémi Denis-Courmont wrote:<br><br>        Le torstaina 23. toukokuuta 2019, 13.57.32 EEST Steve Lhomme a<br>        écrit :<br><br>            Here's another one: we could decide to rewrite libvlc in C++<br>            and keep<br>            the same ABI. Does that mean we would have to forced libvlc<br>            hosts to<br>            call "delete psz-str" because we don't feel like keeping<br>            libvlc_free() ?<br><br>        You would have to keep using malloc() otherwise you would break<br>        the existing<br>        ABI 3.0 or 4.0 anyway that says you can use free().<br><br><br>    That's indeed a problem. I think the free() option should not have been<br>    there in the first place. I would rather vote to remove this option.<br><br>    For example we could decide that for performance reasons we allocate<br>    using aligned_alloc(). On some system that requires an aligned_free().<br>    We cannot do that if we allow free() of a particular runtime.<br><br>        Not only that but delete<br>        would bring rather interesting considerations with RTTI.<br><br>        If you want to abstract that away, you need case-specific<br>        release functions<br>        like Romain pointed out - not libvlc_free().<br><br><br>    It turns out that in many cases it would not be libvlc_free().<br><br>            That would force every host app to embed a C++ runtime just<br>            because<br>            libvlc happens to be written in C++.<br><br>        That example is absurd. In general, just switching LibVLC to C++<br>        breaks the<br>        ABI.<br><br><br>    The extern "C" ABI remains the same, even if it's coded in C++ underneath.<br><br>        Whether it requires the application to have a C++ runtime or not<br>        would<br>        depend on the platform. In many cases, it actually would indeed<br>        need a C++<br>        runtime regardless of libvlc_free().<br><br><br>    Yes, running a C++ libvlc will require a C++ runtime. That doesn't mean<br>    the libvlc host has to deal with it. Again, in Windows this is hidden<br>    when loading the DLL (dunno how .so loading works). There is no reason<br>    to force the host to call the C++ delete. Just like there is no reason<br>    to force the host to call the C free().<hr>    vlc-devel mailing list<br>    To unsubscribe or modify your subscription options:<br>    <a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a><br><br><br>-- <br>Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser <br>ma brièveté.<hr>vlc-devel mailing list<br>To unsubscribe or modify your subscription options:<br><a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a><br><br></blockquote><hr>vlc-devel mailing list<br>To unsubscribe or modify your subscription options:<br><a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a></pre></blockquote></div><br>-- <br>Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.</body></html>