Hacker News Reader

Comment by jstimpfle | Hacker News Reader

> I haven't met or know anyone mastering C/C++ (especially C++), and doubt I'll ever hear about one.

C can definitively be mastered. C at it's core is pragmatic minimalism. The basic ideas are very simple. If you want to be a language lawyer and know the standard completely (including all historical accidents), it can get complex, but still manageable. But anyways, you shouldn't be a language lawyer. That's not C. Make maintainable programs instead, stay in the middle of the road.

C gets out of the programmer's way. It's not about mastering C, but about mastering programming. And while I agree there's much bad C software out there: I haven't seen one maintainable non-bloated Java project. Here is one master of C that I'm sure you know: Linus Torvalds. Of course there are many, many more. Just remember it's not about C, but programming machines in general.

View on HN

> 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.

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.

> 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.

> C can definitively be mastered.

If that's true, how come there are almost no widely used network facing C programs that didn't have plenty of security vulnerabilities?

(Anything written by Daniel J. Bernstein doesn't count, because there's no way he's a mere mortal. :))

Which language has? Keep in mind market share, so don't say Go.

Even djb had flaws in his C code despite being a semi-god. It took a $10k bounty and several years to be found but it was there !

OpenBSD has done a great job, especially if you look at what they achieved, how fast they got there, and what resources were at their disposal.

Qmails direct competitor Postfix? Postfix has more, but Qmail has one with a higher score: https://www.cvedetails.com/vulnerability-list/vendor_id-8450... vs https://www.cvedetails.com/vulnerability-list/vendor_id-86/p...

Postfix is also much more widely used than qmail.

for, while, do...while, recursion, goto: is not a sign of "pragmatic minimalism" unless one choses to define it tautologically as "what C has".

Pragmatic == close enough to all of the popular and contemporary assembler flow control constructs.

"recursion" is not a concept in C. Just function calls. "for" and "while" are very simple concepts and basically the same. They are very simple and well known idioms and not C specific. Most languages have both - not a big deal. I use "for" mostly for iterating over arrays, and I have otherwise mostly while loops and while(1) loops with manual breaking.

Goto, you just can't do without it.

Also not saying that in some cases even C is too much abstraction. But in general, its memory abstractions and its function call abstraction have proved to be very effective helping humans develop in a modular fashion.

> Goto, you just can't do without it.

Strange, the last time I used it I was still doing Basic in the early 90's, or when I do some Assembly programming.

So yeah, we can do without it, as long as the languages are powerful enough.

I do find forward gotos useful in C. For error handling and breaking out of nested scopes. But only when goto is simpler and easier to understand than the alternative.

Not saying there's no use for backward gotos, just don't remember ever needing them. Maybe they could be useful for some C code generation cases or perhaps for retrying some operation?

What really annoys me are C++ exceptions used for flow control. Surprise gotos. I loved exceptions long ago at first, but over time the feeling has shifted more and more towards hate. Exceptions make code bases so much harder to understand. Especially when combined with inheritance.

> "recursion" is not a concept in C. Just function calls.

There are indeed C compilers that don't support recursion (or function re-entrancy). What does the standard say about stacks?

I'm not a standards guy, so I might be wrong, but this is the only reference to recursive calls that I could find from the C11 draft [1], Section 6.5.2.2 item 11:

    Recursive function calls shall be permitted, both directly and indirectly through any chain of other functions.

Stacks, I don't know. I only care about the concept (and semantics) of function calls. The call stack is an implementation detail. I wouldn't be surprised if the concept of a call stack was not part of the standard.

[1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

Indeed, it's not. In the case of what we'd usually call stack-allocated variables, the C standard just uses the phrase "automatic storage duration", and defines their lifetime without explicitly referencing a stack:

> For such an object that does not have a variable length array type, its lifetime extends from entry into the block with which it is associated until execution of that block ends in any way. (Entering an enclosed block or calling a function suspends, but does not end, execution of the current block.) If the block is entered recursively, a new instance of the object is created each time. The initial value of the object is indeterminate.

> C at it's core is pragmatic minimalism.

Pragmatic minimalism as it was for the hardware at the beginning of the 1970s, to be exact.

The C machine model is still the only model I can easily program and not make a mess. And without being a hardware architecture expert: Has so much changed on the assembly level? And what other languages are truer to today's machines?

None of them are, not even Assembly, unless the CPU executes the opcodes directly in hardware without micro-code help.

The C machine model says nothing about vector instructions, instruction re-ordering, NUMA, GPGPU, IO ports, Harvard architecture, multi-core.

As of C11, the C machine model does (finally) include threads and memory ordering, so at least you can say it says something about multi-core…

Modern C compilers do enormous job of optimizing C code, despite its shortcomings like the lack of distinction between pointers and arrays. You don't need to worry too much about that, maybe you'll need to sprinkle vectorization intrinsics or assembler code if the compiler isn't smart enough, or to add a couple of memory barriers.

Would mostly sign that, but not without inspecting security or performance critical code in disassembler.

Modern compilers are still rather bad at vectorization. What's worse, those optimizations are often unstable. A small change might make code several times slower. Performance regression tests and when that fails, vector intrinsics are a must.

Reply on news.ycombinator.com