Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

"Just about every software project written has some serious bugs"

There, fixed it for you. Seriously, vulnerabilities and bugs are found everywhere not just in C.

I've been programming for 35 years, in so many languages I lost count, and every time I've seen the 'let's not use C because it'll lead to bugs' it was to be replaced by another thing that was ALSO leading to bugs, and/or become so bloated it was in itself... a bug.



> Seriously, vulnerabilities and bugs are found everywhere not just in C.

The black-and-white security fallacy again!

The simple fact (and this is a fact, not an opinion) is that the most severe security problems—remote code execution, in particular—are found way way way more in programs written in C and C++ than in other languages.


I strongly agree with your point in general, memory safety is a major problem with C/C++ to an extent that is not found in other languages. Even worse, these often become problems long after they are written when the compiler gets "smarter" and does a trick with your code. Call it "code rot" or whatever you want, but it happens a lot more and a lot faster on C/C++ than other languages.

However, the nature of where C/C++ code is used does lend itself to severe problems. When you have a JVM vulnerability, you shouldn't be able to get any farther than a regular user with only sandbox privileges. When you have a kernel vulnerability, by definition you have the keys to the kingdom.

Of course there are always holes that can be used to escalate, but that also comes back to the problems of having a primarily C/C++ ecosystem...


Per unit of code or as an absolute value? That's significant, but not even the whole picture. It's trivial to have a low (absolute and per-unit) number if the total number of units is low, for example. So by itself your fact is almost useless.


The big problem with C is the memory safety issues. It is extremely difficult to write C code and be safe from malicious input. If you use a memory safe language these difficult issues are erased.

I realise the compiler/runtime can't stop all bugs but fixing these simple errors goes a long way to producing robust secure software.


I am sorry, but there's nothing difficult about it. Tedious, yes. Difficult? No.


I hope you will agree that there are things where C is not the optimal choice (e.g. you wouldn't choose C for writing scripts). Many people argue that C is still suitable if you need maximal performance or do stuff that is very close to the hardware, like operating systems. Now, people who say that C shouldn't be used at all are just convinced that even in those applications there are now better choices than C. Safer languages like Rust exist that at least claim to fill the same niche as C.


A: "Let's not reuse syringe needles, it leads to spread of HIV".

B: "I've been using syringes for 35 years and clean needles won't get rid of HIV entirely".

Well no duh. But that isn't really a counter argument.

> become so bloated it was in itself

Whereas C is the pinnacle of expressiveness?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: