I guess what jacquesm was getting at was that instead of extending C, the world should have left C behind a long time ago and transitioned to other, safer languages.
These days there are excellent alternatives to C, but of course we also have vast codebases written in C that would be too big of an undertaking and too much of a risk to rewrite in a safer language.
There may not have been any sufficiently widespread alternative in the past in terms of developer mindshare, and sufficiently performant considering how limited the hardware was in terms of both speed and memory and storage. There is also the issue of portability and of embedded platforms, and that remains problematic to this day in some cases but in other cases the possibilities for using safer languages are already really good.
Even in cases where an alternative was known and suitable, people in the past had legacy codebases that they were working with too that they didn't want to risk rewriting in any other language. So they just kept adding to the code that they had.
The legacy-code that we are sitting on now is so many lines of code that one might wonder, was it even justified that they didn't want to take on the risk of rewriting the code in the past, while there still was a chance to do it all in one go? Maybe, maybe not.
Either way, we can do nothing about the past, but if we keep growing the legacy codebases, the problem only gets bigger in the future.
We should not strive to rewrite it all at once, but we should use safer languages when we extend our codebases, and we should use safer languages when we start new projects.
Every line of code that we write today adds to the amount of code that will make up the legacy code of tomorrow.
Let's strive to make the legacy code of the future safer, so that our children may run their societies on safer software!