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

[Steve Lhomme]

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
>