On Thu, Feb 27, 2025 at 2:02 PM Michael Niedermayer <mich...@niedermayer.cc>
wrote:
> 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
>
>
>
```
$ cat > /tmp/foo.cpp
int main(int argc, char **argv) {
int *v = (int*)(void*) new char; new int;
delete v;
return *++v;
}
$ g++ -g -Wall -fsanitize=address -o /tmp/foo /tmp/foo.cpp
$ /tmp/foo
=================================================================
==14416==ERROR: AddressSanitizer: new-delete-type-mismatch on
0x602000000010 in thread T0:
object passed to delete has wrong type:
size of the allocated type: 1 bytes;
size of the deallocated type: 4 bytes.
#0 0x7fd6348debb8 in operator delete(void*, unsigned long)
(/usr/lib64/libasan.so.4+0xdebb8)
#1 0x40078e in main /tmp/foo.cpp:3
#2 0x7fd634040e6b in __libc_start_call_main (/lib64/libc.so.6+0x40e6b)
#3 0x7fd634040f34 in __libc_start_main_alias_1
(/lib64/libc.so.6+0x40f34)
#4 0x400680 in _start ../sysdeps/x86_64/start.S:115
0x602000000010 is located 0 bytes inside of 1-byte region
[0x602000000010,0x602000000011)
allocated by thread T0 here:
#0 0x7fd6348dd830 in operator new(unsigned long)
(/usr/lib64/libasan.so.4+0xdd830)
#1 0x40076f in main /tmp/foo.cpp:2
#2 0x7fd634040e6b in __libc_start_call_main (/lib64/libc.so.6+0x40e6b)
SUMMARY: AddressSanitizer: new-delete-type-mismatch
(/usr/lib64/libasan.so.4+0xdebb8) in operator delete(void*, unsigned long)
==14416==HINT: if you don't care about these errors you may set
ASAN_OPTIONS=new_delete_type_mismatch=0
==14416==ABORTING
```
As to why the compilation of this code did not issue any warnings -- that
should be directed to gcc, not C++ experts
A C++ expert would not write code like this ...
With C++ you have the same freedom to write bad and leaky code as you can
with C, but you also have the tools (RAII) to write safe code.
Pavel.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
