Flash is theoretically a "safe" language. Maybe they should have implemented the flash runtime in a "safe" languange... like java? or javascript? But wait, those are also implemented in an "unsafe" language!
Yes, there are "safe" languages which are compiled to machine code by a compiler written in that "safe" language. But there are still horrific security bugs which are not related to memory safety, in feature-packed super-popular web-facing software, like Rails or various PHP frameworks, where they automatically take some part of a request and inject variables in execution scope or even put user input through a yaml parser which will instantiate objects with constructors.
Using C isn't guaranteed to make software insecure (OpenBSD and DJB demonstrate that), while not using C isn't guaranteed to make software secure. Maybe it helps, maybe a lot. But you also need to care about code quality and security, and understand your own level of competence, and do the right thing.
It seems evident that if you care a lot about the features and backwards-compatibility with those features and not about code quality for a number of years, then even if you later care about security (and thus code quality), it's too late. The mess is too big for your organization to fix it.
> But wait, those are also implemented in an "unsafe" language!
The typical remark from those that don't get how compilers work.
There are Java compilers implemented in Java, just because OpenJDK isn't one of them it doesn't change the fact that they do exit.
Also why does the OpenJDK use C++ then?
Historically accident, the compiler/JIT weren't never bootstraped by Sun so the code lives on, but it gets replaced by Java code in each JDK release, step by step.
> Using C isn't guaranteed to make software insecure (OpenBSD and DJB demonstrate that)
Like OpenSSH? Nice proof of writing secure software in C.
Yes, there are logical security errors that plague languages even like Ada/SPARK.
However in 2015 we shouldn't be fighting against bounds errors and buffer exploits when it was already a solved problem in Algol.
The compiler isn't the issue here, the runtime is, and runtimes inherently have to be written in unsafe code because the underlying hardware architecture and operating system APIs are themselves unsafe. (With the exception of some very obscure and obsolete hardware from the 70s and 80s.)
It doesn't follow that anything but the lowest-level wrappers that call into the OS APIs have to be unsafe. Those wrappers can be a tiny fraction of the runtime code.
Buffer exploits are possible even in bounds-checked languages. Bounds that are checked are allocation bounds, not the logical bounds, which can still be misused on be incorrectly programmed. Some categories of bugs can be eliminated, making everything safe just by selecting any language is not actually possible.
Well, sure, but drawing the conclusion that there's no point in writing in a memory-safe language is like saying there's no point in building bridges instead of building rafts because bridges sometimes collapse.
I only came to C and C++ when using Pascal like languages wasn't any longer an option.
I know my way around systems programming with languages that offer stronger memory models.
I am also older enough to remember when the code produced by C compilers was seen as dog slow and not the speed daemons that everyone now takes them for.
The amount of engineer hours (and money) wasted in language workarounds...