Hacker News Reader

Comment by pcwalton | Hacker News Reader

> I haven't seen one maintainable non-bloated Java project

I also haven't seen one large-scale network-facing C project written using reasonable development practices (i.e. not absurdly expensive formal verification) that hasn't had some sort of terrible remote code execution vulnerability. By contrast, Java programs tend to be far less vulnerable to this kind of problem. (The closest thing is probably bugs with attacker controlled java.io.Serializable, which while severe are much less frequent than RCE in C programs.)

> Here is one master of C that I'm sure you know: Linus Torvalds.

I agree that Linus is a master of C. Linux is also an excellent example of the above problems with C.

View on HN

> I also haven't seen one large-scale network-facing C project written using reasonable development practices (i.e. not absurdly expensive formal verification) that hasn't had some sort of terrible remote code execution vulnerability.

This has gotten a lot better with static code analysis (clang-analyzer, Coverity, ...) and whitebox-fuzzing (libfuzzer, afl, ...). Both simply point you to the bugs and don't require a formal spec.

Together with Valgrind, these tools have revolutionized C programming for me.

These tools are important for legacy code or code that cannot be written in any language other than C. They do not bring C code anywhere near to code written in other languages in terms of security and correctness.

Plus those tools are not available in all C compilers, specially in the embedded world.

I believe BIND9 has never had a remote code execution vulnerability - plenty of denial of service vulnerabilities, though, because it kills itself when it detects memory corruption.

I wouldn't say "mastering C" should imply "never have any security issues". And many vulnerabilities are conceptual and don't have anything to do with the use of C.

Use your tools wisely. Architect programs for clear data flow. Validate inputs as soon as possible. Don't do (de)serialization by hand.

By all means use a managed "memory safe" language if you have many data accesses that are not behind a validation gateway. But for large amounts of data or complex software, that's still not an option. C is still the only language in which I can write software of advanced complexity - because it does not get in my way.

The entire industry has been successfully writing programs that process "large amounts of data" and "complex software" in languages other than C for decades.

Counter-examples: Kernels, Game Engines, Software with lots of small "objects". I once had to write a SAT solver in Java (dozens of millions of clauses) and it was a disaster which I could only rescue by converting to highly unidiomatic Java code. It would have been much more straightforward in C.

> Kernels

Mesa/Cedar at Xerox PARC, Topaz at DEC/Olivetti, Oberon at ETHZ, JavaOS at Sun, Singularity/Midori at Microsoft Research

> Game Engines

Unity is slowly rewriting parts of their C++ pipeline with C#, after their IL2CPP compiler got mature.

Then there are game engines like Xenko being done.

Also being with one foot into games since the 80's, I remember the transitions "Pascal/C are too slow, we stick Assembly", "C++ is too slow, we stick with C", now we are in "JavaScript/C#/Java are too slow, we stick with C++" phase.

Reply on news.ycombinator.com