Hacker News Reader

Comment by npalli | Hacker News Reader

> 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.

View on HN

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.

> 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.

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

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

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

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.

Reply on news.ycombinator.com