> The problem is not the language! It is. A language that lets you write unsafe code is an unsafe language. > If C is not sufficiently safe for you, you shoul

> The problem is not the language! It is. A language that lets you write unsafe code is an unsafe language. > If C is not sufficiently safe for you, you shouldn't take planes, or drive cars, or rely on medical devices, because the software of all these critical embedded system is written in C. Citation needed. I would expect those programs to be written on a language with very strict types and no pointer arithmetic bullshit, like Ada. And even if some of these software pieces are written in C, (a) that's very bad, too, and (b) it may be more suitable for those scenarios. But a program that reads and parsers unlimited amounts of user input, supports an ever growing list of complex (and often improperly defined) protocols, and is edited/expanded/updated daily, is definitely not such a suitable scenario. > The problem is on how you write the software. There are projects that have strict code standard, such as MISRA C or even stricter ones. Again, the problem is the language, not how you use it. If the security of a piece depends on how it is manipulated, it is by default insecure. A secure language shouldn't let users make mistakes (or at least avoid them to a very high degree, both in compilation and run time). And a library that is the backbone of the confidentiality and privacy of millions of people (and billions of dollars in businesses) should be written on a secure language.