[npalli]

> We're really talking about resistance to memory safety in the last redoubts of unsafety: browsers and operating systems.

.. and other performance critical areas like Financial applications (HFT), High Performance Computing (incl. AI/ML), embedded, IoT, Gaming/Engines, Databases, Compilers etc.. Browsers and OS are highly visible, but there is a gigantic ton of new C++ code written everyday in spite of the availability of memory safe languages.

[tptacek]

People keep coming up with all these examples of things still written in C/C++. Sure. So are most AAA games. But so far nothing that's been identified --- maybe excepting databases, but vulnerabilities there are still rare --- that is a meaningful component of insecurity, which is what "memory safety" addresses.

[spacechild1]

> that is a meaningful component of insecurity, which is what "memory safety" addresses.

There are plenty of people, though, who argue that everything must be memory safe (and therefore rewritten in Rust :) I personally don't agree with that sentiment and it seems like you don't agree either.

[tptacek]

It would be better for everyone if everything on a forwardgoing basis was written in a memory-safe language.

[spacechild1]

What difference does it make for a video editor or DAW?

[adgjlsfhk1]

iphones have already CVEs from memory safety issued in image formats. is entirely plausible that a similar issue could exist in video or audio codecs

[wolf550e]

The parser is attack surface, but that's the only part of something like Photoshop that has to be secure. The actual editing features can be insecure.