On Wed, Feb 26, 2025 at 03:11:13PM +0100, Tomas Härdin wrote:
> sön 2025-02-23 klockan 22:51 +0100 skrev Michael Niedermayer:
> > Hi
> > 
> > On Sun, Feb 23, 2025 at 10:30:03PM +0100, Tomas Härdin wrote:
> > > lör 2025-02-22 klockan 14:57 +0200 skrev Rémi Denis-Courmont:
> > > > Le perjantaina 21. helmikuuta 2025, 20.02.16 UTC+2 Tomas Härdin a écrit :
> > > > > The above said, I'm not against Rust. It has some nice properties. But
> > > > > it does not seem very "stable" so far. Perhaps this has changed in
> > > > > recent years..
> > > > 
> > > > IME, it's become very usable for user-space code. Bare metal still pretty much 
> > > > requires unstable features, but that's not a problem for FFmpeg.
> > > 
> > > I mean more in terms of ABI, and having to have cargo install specific
> > > versions of the Rust compiler and so on.
> > > 
> > > > > If we're in the habit of allowing other languages I'd be in favor of
> > > > > allowing C++, so that we can make use of the STL containers rather than
> > > > > rolling our own.
> > > > 
> > > > Yikes. Rust is actually way saner for type-generic programming than C++.
> > > 
> > > No doubt, but STL is still miles better than rolling our own
> > > containers.
> > > 
> > 
> > > Anyway, rather than shoehorning Rust into this codebase it might make
> > > more sense to contribute to NihAV instead. But only if it has a sane
> > > parsing framework
> > 
> > That misses the point. FFmpeg should support a "safer" language than C
> > because for some modules its the better choice.
> 
> Maybe. We can do a lot by just improving the build system. But if we're
> going that route I think we should first try and see how working C++
> into more parts of the code works, because we already have support for
> C++ for torch and decklink. Doing so would allow us to toss out lots of
> code, especially in lavu, which is always nice. Code is a liability.

can some C++ expert explain me why this builds and runs with no warning ? ;)

int main(int argc, char **argv) {
    int *v = (int*)(void*) new char; new int;
    delete v;
    return *++v;
}

we have a memleak, a use after free, a aliasing violation,
some invalid pointer and a out of array read

a safe language should not allow any of this
C++ allows all of it, its not safe, switching to C++ doesnt help

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch