back
1 comments
I'm almost not. I made the point because this level of ambiguity and "do it yourself" is consistent throughout the language.

I know why we still use C, but the use of C is inherently prone to security problems.

C does not provide bounds checking by default, so it can be forgotten (Heartbleed) and the lack of either static checking, RAII or garbage collection (Not as a library e.g. Boehm) makes memory corruption all but inevitable.

People are forgetting that it is the very "looseness" of C that is responsible for its great success. The sheer volume of code in C (specifically, any number of complex and critical software) is a testament to that. People keep parroting the same old tired tropes about C without reflection and thought. All the problems, both real and imaginary, in the language have been worked through/around since the beginning by simple discipline, guidelines and external libraries. I am always annoyed when people bring up "memory corruption" as if it were some primordial sin. The power to manipulate raw memory in whatever way i want is so crucial that i am willing to live with the downside of possible corruption. In fact most of the people i have worked with and myself never found this to be so much of a problem as everybody else makes it out to be. We always followed good guidelines, had special libraries for memory allocation as needed and testing procedures to catch memory leaks. Everything worked out fine.

In conclusion, the power given to Programmers by C far outweighs any of its perceived downsides in real-world scenarios.

This is fine for your or my software but the risk of these bugs no matter how rare is too great for mass deployed code in something similar to OpenSSL.

Any good alternative still allows you manipulate raw memory, but provide a safe alternative which makes it much harder to fuck up.

What power do I actually lose by using a safer language?

The OpenSSL "Heartbleed" bug that you bring-up is not related to inherent failures of the C language but something else. Just as an aside, i actually have some background in implementation of security protocols (specifically IPSec framework) and FIPS certification for a cryptographic algorithms library, though by no means am i an expert. In the security community many people believe that "Heartbleed" was an intentional plant. See https://www.smh.com.au/technology/man-who-introduced-serious... OpenSSL is such a heavily used and vetted piece of software that the probability of this being an "accidental bug" is very very low and my money is on it having been deliberately inserted i.e. deliberately used C language features towards a nefarious goal. So this is not a good example to bring up.

Now coming to your other point, in today's environment, it is true that you do not lose much for the most part when using a safer language because somebody else has done the dirty work in the implementation of the corresponding language's runtimes, compilers, libraries and ABIs. Without the latter you cannot have the former. After all at some point you have to move out of the cocoon provided by the language and meet real hardware (a good example is bare-metal programming on MCUs). And that is where C is needed and any challengers have to provide exactly similar "ugly, dangerous and unsafe" features if they want to dethrone the champ.