I cannot consistently write safe C/C++ code
robert.ocallahan.org
I cannot consistently write safe C/C++ code
1–10 of 123 posts
Re: I cannot consistently write safe C/C++ code
#2> I cannot consistently write safe C/C++ code.
I'm not sure how to interpret what this means. What do "consistent" and "safe" mean? Is safety about not corrupting program data? Even when dealing with Python arrays, I can end up corrupting my arrays one way or another (off by one, race conditions, etc.). Is "consistent" about going days without a bug? Because I can't do that in any language. If not, what do these mean? It'd be really nice to know what other languages he can write safe code in, so we can have something to compare to.
Re: I cannot consistently write safe C/C++ code
#3Yet another subtle pro-Rust rant against C.
Programming is hard, and writing safe code requires knowledge, not just in C, but in every single language. Even in formal-validable languages you can make mistakes: may be you'll not make errors by using sprintf, but can make others because of using a more complex language.
Re: I cannot consistently write safe C/C++ code
#4> I cannot consistently write safe C/C++ code. I'm not sure how to interpret what this means. What do "consistent" and "safe" mean? Is safety about not corrupting program data? Even when dealing with Python arrays, I can end up corrupting my arrays one way or another (off by one, race conditions, etc.). Is "consistent" about going days without a bug? Because I can't do that in any language. If not, what do these mean…
> Is "consistent" about going days without a bug? Because I can't do that in any language.
Amen to that. Even when I feel like I cover most of the cases, the sands of time will slowly eat away at the foundation, things become deprecated, and new error conditions added all the time.
Re: I cannot consistently write safe C/C++ code
#5I think this whole "competent coders don't make mistakes" is a testament to the immaturity of the software development world. Real men write in assembly, maybe C if they're a bit tired.
It would be like a construction worker saying "only noobs need a hard hat" or a surgeon refusing to wash their hands because they're careful never to touch anything contaminated. Or maybe simply refusing to wear your seatbelt because you're a good driver.
Guns don't kill people, people do but if your gun has the bad habit of firing randomly when you don't want it to I guess it's fair to blame the gun a little bit as well.
Re: I cannot consistently write safe C/C++ code
#6> I cannot consistently write safe C/C++ code. I'm not sure how to interpret what this means. What do "consistent" and "safe" mean? Is safety about not corrupting program data? Even when dealing with Python arrays, I can end up corrupting my arrays one way or another (off by one, race conditions, etc.). Is "consistent" about going days without a bug? Because I can't do that in any language. If not, what do these mean…
I think it is clear what he means from the remainder of the blog post:
I see a lot of people assert that safety issues (leading to exploitable bugs)
It is obvious that he is referring to typical C/C++ safety issues buffer overflows, use after free, etc.
Even when dealing with Python arrays
You can introduce security vulnerabilities in any programming language. But safe languages exclude a host of memory-related vulnerabilities, which are a substantial proportion of all vulnerabilities.
Safety is not binary, some languages provide better safety or better means to model domain data safely than other languages.
Re: I cannot consistently write safe C/C++ code
#7Yet another subtle pro-Rust rant against C. Programming is hard, and writing safe code requires knowledge, not just in C, but in every single language. Even in formal-validable languages you can make mistakes: may be you'll not make errors by using sprintf, but can make others because of using a more complex language.
Good risk management is about cost vs payoff analysis. To address the risk of car accident, first you stop juggling chainsaws while driving, then you start to wear seatbelts, and then you start thinking about how the remaining inevitable driving mistakes can be mitigated through technology or practices.
Re: I cannot consistently write safe C/C++ code
#8> I cannot consistently write safe C/C++ code. I'm not sure how to interpret what this means. What do "consistent" and "safe" mean? Is safety about not corrupting program data? Even when dealing with Python arrays, I can end up corrupting my arrays one way or another (off by one, race conditions, etc.). Is "consistent" about going days without a bug? Because I can't do that in any language. If not, what do these mean…
Consistent as in you can do it while focusing on solving business problems, instead of only when safety is the primary thing you're concentrating on.
Safe as in a minor bug is unlikely to be an exploitable security hole.
Re: I cannot consistently write safe C/C++ code
#9> I cannot consistently write safe C/C++ code. I'm not sure how to interpret what this means. What do "consistent" and "safe" mean? Is safety about not corrupting program data? Even when dealing with Python arrays, I can end up corrupting my arrays one way or another (off by one, race conditions, etc.). Is "consistent" about going days without a bug? Because I can't do that in any language. If not, what do these mean…
You can have "safe" buggy code as long as you avoid the subset of bugs that can open a security vulnerability. It's possible to make such a mistake in any language but some make it harder than others. C's laissez-faire approach to memory management makes it very easy to introduce a small bug that leads to a major security vulnerability.
Indexing out of bounds in python throws an exception. Indexing out of bounds in C triggers the dreaded "undefined behaviour". Here be dragons.
Re: I cannot consistently write safe C/C++ code
#10Yet another subtle pro-Rust rant against C. Programming is hard, and writing safe code requires knowledge, not just in C, but in every single language. Even in formal-validable languages you can make mistakes: may be you'll not make errors by using sprintf, but can make others because of using a more complex language.
Good risk management is about cost vs payoff analysis. To address the risk of car accident, first you stop juggling chainsaws while driving, then you start to wear seatbelts, and then you start thinking about how the remaining inevitable driving mistakes can be mitigated through technology or practices.
Sure. And the best "insurance" is having competent programmers.