What I find surprising is when people say C is a simple and small language that's nice to build portable programs in. So much of C is undefined behavior or implementation specific that many professional users pin a certain compiler toolchain version for a project. Part of it is due to changing and hard to predict optimizer passes, but most of it is due to the purported portability feature of C. I mean, if I leave a lot of the semantics undefined or to be defined per compiler+target, then it's not really a portability abstraction. Not to mention the missing or, if you consider POSIX, inconsistent across platforms, C stdlib.
It's educational to look into Modula-3 and SPIN. SPIN is like MirageOS but with dynamic loading of components whereas in Mirage everything is compiled ahead of time into the final image. I mention Modula-3 because it's of similar age as ANSI-C and serves as an example of an OS written in a comparatively safe language around the same time Unix won and gave us the hegemony of C (with all the avoidable security fallout ever since).
Even though software isn't like the real world and could be improved substantially unlike world politics, we still continue dealing with bugs due to C, although we have better options. I think as long as new operating systems or libraries and applications are written in C, this won't change. Just the idea of writing kernels for IoT systems in C in 2016 makes no sense from a reliability and high assurance perspective. Getting there half way would be exposing hard-to-misuse C APIs where the implementation is in a safe language (Rust, ATS2, etc). For the moment consuming C APIs is the cross platform library interface we have to deal with, but having at least the implementation be safe would go a long way.