4 ms·
Why not blame the language? There are plenty of languages available that are objectively more safe than C. Most of the security-critical memory-related bugs th
by rossng 11y ago
Why not blame the language?
There are plenty of languages available that are objectively more safe than C. Most of the security-critical memory-related bugs that are written in C (and C++) simply could not happen in, say, Java or Haskell.
By contrast, even though it is technically possible to write safe C, it is mind-bogglingly hard. The problem is too difficult to be solved even by automated static analysis, testing and fuzzing.
The reason those safe languages aren't used pretty much always boils down to either a) legacy or b) performance. Rust solves the latter, but the former is nigh intractable.
Simply expecting programmers to be better or more careful is not a viable solution. The aviation industry knows this - problems can almost always be attributed to a systemic cause, not the one-off mistake of an individual. Problems are fixed by making those mistakes impossible, not by reminding people not to do that, crossing your fingers and hoping for the best.
This attitude is spreading to other industries - primarily healthcare[1]. In the light of the ever-growing digital security threat, I think we should be making the same kind of efforts in software engineering.
C has its niche, but I think it is important to recognise that it has its tradeoffs. We should be trying to make things better.
[1] http://www.amednews.com/article/20100614/profession/306149945/4/ http://www.amednews.com/article/20100614/profession/30614994...
- seanwilson 11y agoExactly, if a language makes a mistake virtually impossible to make, why would you not want to take advantage of that? If there's even a small chance you can make a mistake, it's inevitably going to happen given a large enough project. For issues like security it's not scalable to just "be careful". Also, as a programmer, I like to automate tedious problems away. I don't understand why a programmer wouldn't want to automate away such a enormously important issue.
- xamuel 11y agoIt's a real dilemma. Sure, the safeguards make your code 5% less performant; who cares, right? Now suppose your code has a dependency, which has a dependency, which has a dependency, which has a dependency. And each level introduces a 5% performance hit. Suddenly your product is 28% less performant. This is why you end up with such nonsensical things as, e.g., the OWL API needing 2 gigabytes of RAM to hold an ontology that should take 200 megabytes max.
- seanwilson 11y agoDo you have links to any benchmarks about this? I can't imagine bounds checking in practical programs has that much impact. For what impact it does have you have to weigh that against the impact of security exploits. Most languages with bounds checking have ways to eliminate bounds checks in certain scenarios as well.
- rancur 11y agopeople making noob mistakes in C and not learning gives me legitimate excuses to fire someone when I feel angry. Java? no excuse