> one wonders what possible harm could come from leaving image decompression buffer faults from maliciously crafted jpegs in popular browsers and software unattended
This is yet another reason a switch to a memory-safe language like unsafe-free Rust is highly imperative.
For this work we don't need a general purpose language like Rust.
WUFFS is a special purpose language for Wrangling Untrusted File Formats Safely:
WUFFS pays a high price (loss of generality) for a valuable reward (compile time assurance of memory safety, very high performance) and it makes no sense for people to hand roll this sort of software in C when they should use WUFFS.
Wow, WUFFS is amazing. I wonder if a hypothetical new/future general-purposes language could have a non-Turing-complete subset within it with WUFFS-like guarantees.
While I think the move to safer code through Rust and other alternatives is a nice breath of fresh air, I doubt you can get these kinds of optimization without using unsafe code in Rust. These optimized implementations often require some kind of safety-bypassing memory modifications to work as efficiently ad they do.
Oh wow, I didn't realize there were mountains of Assembly in there. If this is the case, I'd say: let's put libraries like this Docker-like containers (in their processes with their own address space), and use mmap/etc-based highly-efficient IPC to interact with them.
With all the hyper-optimized assembly in there, it's probably still more efficient even with the container penalty (which, tbh, is close to zero on Linux these days).
...at which point the code written in C will suffer from BOTH categories of bug, while code written in any language whose compiler guarantees memory safety will not.
Guaranteeing memory safety isn't just an overhyped benefit meaningful only to Rust fanboys. It is also one important reason why much code is written in Java, Python, or JavaScript. It is a valuable property for any language to have.
I think you might need to define what exactly you mean by "memory safe".
There is an entire class of bugs common to C and C++ that absolutely never happen in JVM languages, CLR languages, Rust, etc. This particular class of bugs of bugs never happen by design, because the language design simply does not permit them to occur ever.¹
¹ I am obviously of course excluding bugs/exploits/unintentional-loopholes here that are in the JVM or CLR, or in the Rust compiler itself, that permit a program to "break out of its box", so to speak.
This is a super-well-known issue with reference counting in general. It would be something to deal with anywhere one uses reference counting exclusively. For example, this is a problem in Swift as well: https://docs.swift.org/swift-book/documentation/the-swift-pr...
Does that mean Swift is unsafe? No.
All this does is create the potential for a memory leak. Which is nowhere close to being in the same category as a buffer overflow exploit.
Also, I suppose one could write a garbage-collected pointer library for Rust, which adds cycle detection (and auto-deletion) on top of ARC.
This is yet another reason a switch to a memory-safe language like unsafe-free Rust is highly imperative.