I didn't get that impression when I used it, if it does that then most likey your code wasn't so standard or your understanding of the language was incorrect.
I personally only got in trouble in C when trying to be too clever.
You're missing the point: writing secure code is categorically impossible, no matter what the language. That's very much different from 'other languages allow some people to write insecure code occasionally'. Every piece of code, every system ever built and every piece of hardware ever designed had bugs in it and if that item was supposed to be secure over time it will turn out that it wasn't. So the best you can hope for is that an item is obsoleted before you (or an adversary) detects its flaws and you're going to be fighting a rearguard action.
The whole idea that many eyes or 'safe' languages or some other magic bullet are going to solve this is so far off-base that it makes productive discussion impossible because everybody starts to focus on the particular tool at hand whereas the real problem is an instance of of the class 'architecture', not of the class 'tool'.
I don’t think I’m the one missing the point. You seem to be rebutting points I didn’t make, like other languages (or magic bullets) afford a bug count of zero. You also seem to be ignoring my point, which is that C is in a different ballpark than other languages in its difficulty of implementing correct software.
you did say that other languages are more secure, and the parent post here is asserting the entire platform is insecure therefor no languages are secure, which is true.
however i disagree with both of you that writing safe C is hard. most of the problems i see relate to incorrect pointer usage or memory management. use stack allocated containers from libs very well tested and pass references. this removes entire classes of bugs from popping up. one thing you can’t do with C is be lazy.
I absolutely guarantee that if you throw AFL at any modestly complex C program that you have written that it will find bugs. Guarantee. This isn't about laziness.
safe and bug free are different things. nobody writes big free code but writing safe code isn’t as hard. also i’m not entirely sure how a program proves lack of laziness, if anything it proves laziness
Many of the most expert C programmers have reported an inability to write secure C code. But you’re right that my understanding of the language is incorrect; that’s largely my point. There are so many oddities and exceptions and surprises that the language is very hard to understand correctly. The people who profess to “not have these problems” haven’t written code that has run the gauntlet of security and widespread multiplatform distribution.
I misunderstood your question. I don't know of the specific reasons; presumably they're the same reasons that intermediate C programmers can't reliably write secure C.
I personally only got in trouble in C when trying to be too clever.