In the majority of places in your code, manual memory management gives you no benefit but does expose you to a possible vulnerability if you make a mistake. If the default, lazy option were to let the well-tested runtime do the job for you, yet you could do a little extra work and get manual override wherever you wanted, and manual override everywhere brought you essentially back to C, I think we would have much safer code without a noticeable loss of performance.
Edit: I just realized in the shower that I was saying "memory management" when I meant direct "memory manipulation" more generally. I'm including arrays accessed by memory address rather than by bounds-checked index, pointer arithmetic, etc., not just malloc and free.
That's true, but I would claim something even stronger. Getting safety doesn't mean giving up manual memory management, as Rust shows (disclaimer: I work on Rust). You just have to need to have a language or system that enforces that you use safe manually-managed idioms. The idea that safety requires giving up performance (e.g. opting into a garbage collector, or even a runtime) is not true in most cases. In a properly designed system, safety doesn't even require opting into a runtime.
The reverse situation, garbage-collecting systems that do nothing to prevent you from dereferencing null pointers or going out of bounds, is just as dangerous as C.
http://www.pwn2own.com/2014/03/pwn2own-results-thursday-day-...
I'll bet it was ocspd they exploited. The CRL handling code in libsecurity is awful, and ocspd runs as root without a sandbox profile.
% ps aux|grep ocspd
root 534 0.0 0.0 2442712 2036 ?? Ss 3:53PM 0:00.04 /usr/sbin/ocspd
% grep -A3 ProgramArguments /System/Library/LaunchDaemons/com.apple.ocspd.plist
<key>ProgramArguments</key>
<array>
<string>/usr/sbin/ocspd</string>
</array>
pgrep -lf -U root | grep processname
or:
ps aux | grep root | grep processname
Air gap AND lasers, how cool is that?