How can C Programs be so Reliable?
tratt.net
tratt.net
Of course I'm generalizing, and a lot of C# programmers write great and reliable code. The point is that they often don't -need- to write great code, because lousy code is good enough for all business purposes (except when the software is your product, which is rarely the case).
The second issue is that people who choose C for their projects tend to (a) understand low-level concepts, (b) care about speed / memory usage / reliability / dependencies, (c) don't consider development time that important. That you create more reliable software that way is obvious - the same programmers would create reliable software in C# (or similar language). But there aren't many situations in which development speed doesn't matter, speed and memory usage don't matter, dependencies don't matter but, for some reason, reliability is very important.
One instance is a colleague who needed to do data post-processing, and just did it in C because it was most familiar. A language like Perl or Python would have been a better choice, and saved him time in the long run, since string manipulation in C is tedious and error prone.
But I agree, C isn't the best choice for that task.
In the 90s it was Visual Basic, now it's Java and C#, but it has absolutely nothing to do with what most of us consider to be discussion worthy.
It just runs our banks, hospitals, governments... Much better to solely focus on those that write kernels, device drivers and filesystems?
That's the kind of programmers this industry attracts, and that's the kind of software it builds. What's so interesting about it? Why even bother mentioning these numerous java/C# jobs? My ex-wife with zero programming experience has trained herself in less than a month to run a simple SQL queries in Visual basic and blast results in a grid control on a form, so did thousands of ex-taxi drivers in late 90s. So?
If you are heavily into programming, as it seems you are, I can understand that SQL queries seem trivial and boring. If your interest is elsewhere programming is often just a tool used to create the interesting stuff. Whether that is usability, design, getting people to interact in new ways, launching rockets or automatically turning off your garden lights when your computer powers down.
Believe it or not there are interesting discussions to be had about other things than programming.
To be honest, I'm still not sure what point you're trying to make is. At best it's somewhat of an Ad Hominem attack.
"People often write in higher level languages because they want lots of bad code fast."
Even if this is true, it's true only in enterprise software environment where code quality has never been terribly important. Therefore it can't really be an argument against higher level languages in the context of a typical HN discussion.
Makes sense?
I'm in no way trolling here, but if you think about it, most of the guys working on startups are also producing lots of bad code fast. The only difference is that most of them are aware of it, and will improve the code based on the requirements from the market.
People often write in higher level languages because they want lots of bad code fast.
Your second assertion is spot on. If one needs to develop a high performing solution optimized for speed and memory consumption, plus high reliability and if it also needs to be reasonably cross platform, one would gravitate towards C. Add to this the established heritage/ecosystem and the tools, and availability of a (relatively) big pool of programmers, C tends to be a good choice.
The only con is a relatively longer development cycle. (True only for mortals like me though, some people stream out C code faster than i write an email. :-) )
This gives you the advantages of a high level language where the extra overhead and consequences for coding a little poorly aren't as detrimental.
Consequently, his perspective on C is that of somehow who is new to the language, yet also understands both the fundamentals of what his code will compile down to, and the higher level facilities that later languages and programming models abstracted away.
In particular I've spent last week trying to figure out TCP/IP port management and it was quite frustrating. Lack of docs and plenty of hardcore operations unexplained, not explicitly marking all macros and inline functions, no clear distinguishing of scope for objects, and I could go on for a few dozen more lines of this.
Only a fanboy or an egomaniacal author can argue that. Don't get me wrong, I like it overall and I prefer it to most other OSs.
I see Linux developers talk about regression tests but couldn't find where is the central repository of this (is there one?) Regression tests IMHO should be distributed with the source code so everybody can run them. (I understand testing a kernel is not like testing any other user space program.) The BSDs do it, for example.
I remember reading about a study about a very different style of development from years ago, where automated testing was NEVER done, but instead formalized models of the program were created and mathematically verified.
If I remember correctly, the final result was a similar level of quality to an extensively tested system developed today, and the code tended to be of somewhat higher quality thanks to the extra thought put into it. (But I'm only going off vague memories here... I might be misremembering)
I'm actually quite disappointed to see my original comment with a negative score. I'm going to assume it was just badly phrased, as I don't seriously think that anyone believes that more testing of software results in a decrease in quality.
I've seen projects with more tests than code, and I think that shows a problem with development methodologies. Simply reasoning about the flow through the code (and possibly using a powerful type system [think Ocaml] to help catch errors at compile time) would remove the need for many of these tests (not all tests should go, of course) and would result in tighter code.
I do think having a suite of repeatable test cases you can run against developing software is a useful thing to have, though. Not only can you test for correctness, but you can also run benchmarks against each modification to see if your performance or memory usage is going up or down.
It probably depends on what you're trying to do...
The coding style is consistent - I don't think I've ever seen a single deviation. Linux kernel code is fit for print. This helps enormously with readability. It's rare to find such a large codebase written by so many people that uniform.
The directory structure and file names are straightforward. Want to know where the main scheduling code is? kernel/sched.c. What about the data structures for scheduling? include/linux/sched.h. How is fork implemented? kernel/fork.c. This is important because it means the source is discoverable.
Functions are just the right length. A single function conceptually does one thing, as it should. I've never read through a function and thought "This should be factored out into several different functions."
Consistent and intuitive names. Even if I've never read a function, or seen the definition of a variable, I have a good idea of what it does just by the name. This is should be true for all code, but considering the size and complexity of the code, I find it impressive I've never thought "That's a stupid name." It helps that special functions follow certain naming conventions. For example, if I encounter a function named do_foo(), I know that it is the function called for a foo system call.
And most importantly, any time I've wanted to know how something works in the Linux kernel, I've always been able to figure it out with focused study and tracing. Focused study, not a heroic effort. If it takes longer than I thought it would, it's always because I had to learn a few new concepts along the way, not because the code was obtuse.
Reading the Linux kernel code helps if you do it using LXR, http://lxr.linux.no/, which does a cross-reference of the code. Most variable names, functions and structures are links to their definitions and occurrences.
My dislikes are more pragmatic, no good comments, packing multiple complex operations in a single line, and not making clear what is what (OK this last bit is style but every single coding style for C out there defines this!)
[Again, I'm playing a bit Devil's Advocate as I'm a Linux user myself. There are many things I love from this team.]
* understand the problem domain
* know the implementation language and its supporting library
* pay attention to detail
Admittedly, some languages fit some problem domains better than others, but 90% of the time, picking the language you're personally most familiar with will be as good a choice as any.
- A whole lot of C code is old. Old, actively maintained code, tends to be more reliable than new code.
- C tends to be employed in relatively predictable sub-systems. Something like a device driver has a relatively predictable set of states relative to a GUI application. There aren't that many paths. C code for GUIs, in my experience, tends to be at least a buggy as code in other languages.
Also a big part of embedded systems have to be reliable for years in hostile environement without external interventions. so I wouldn't say that this is easily predictable subsystems.
Unpredictability seems to arise mostly from interuptability. GUI applications have the ability to jump from a large bank of states to another large bank of states with almost endless permutations and maintain several, not one state simultaneously.
At least in systems programming and I'd assume embedded programming (and like I said, I'm guessing -- I'd be interested in your take there) the chain of interruptability is much more structured and the logic flow inside of components is much more atomic.
Some people have to deal with the machine, and C is a good model of the machine. Even reliable systems have some core in C (or an equivalent) that provides an abstraction where higher level abstractions can be expressed.
Testing isn't the ultimate solution; some people are just able to use the machine better and produce better code. Testing crappy code doesn't really help. A subset of developers produce tools where others can produce systems with less risk by providing appropriate abstractions.
C has been gaining traction in embedded avionics software, which is purposefully very simple, understandable, maintainable code, and tested & verified beyond nearly any other type of software.
C is also used on mobile phones, where it's more hit & miss, as I'm sure many of us have experienced first-hand...
In some cases old, actively maintained code is more reliable. However, I have seen many cases where old, actively maintained code (depending highly on the quality of the maintainers) has lost reliability because the original principles of the codebase have been lost.
Device drivers (especially in multiprocessor systems) have very many unpredictable paths. In my experiences in writing devices drivers and GUI code code (as well as lots of code in the middle), device drivers are more likely to have the unforeseen codepath. With GUI code, you can constrain concurrency so that possible codepaths are also reduced.
As the author alludes to as well - in C you're made more aware of the error conditions you can handle and the ones you can't. So you can code to a level of robustness... Exceptions in Java are all well and good, but I haven't seen many implementations that do anything with IOException except for cascade it.
This works really well for programs/modules that can fit in the head of a single programmer. When you go beyond that it gets pretty messy - which is where some of the advantages of metaphors like OO start to help... Course, there is the argument that modules should never get that big, but that's another debate.
You mean like when a function silently returns -1 to indicate failure and then you wonder why your program returned a wrong result (if you're lucky enough to even notice)? In the bigger part of most of my programs I want a big, flashy, loud, total failure by default if anything goes wrong.
What you're saying is that you want your programs to blow up when a function returns a known error (such as "disk full").
One of the points of the article is that C makes you think about all the possible, well-documented, errors that each function can encounter. You know when you write C precisely what can go wrong at each stage, and decide the right way to handle it.
Seeing a dialog box pop up with some exception backtrace is one of the things that annoys me about 'modern' Java-esque languages: they seem to encourage developers to default to ignoring most exceptions.
I think the space between to two is more uncomfortable than either extreme.
One of the most interesting papers I read was "Why computers fail and what we can do about it" by Jim Gray while he was at Tandem. Transactions are essential, and most failures are transient. This can be applied at many levels, and can deal with many failures without the developer of the mainline code having to decide what to do for each given failure.
if ((result = foo()) == -1) {
fprintf(stderr, "!$*!$&^!$*!!!!\n");
exit(1);
}Failing loudly is the only sensible behavior when an unexpected error occurs and there's absolutely no indication of what to do in such a case.
tyger(~)% cat << EOF > main.c
? #include <assert.h>
?
? void main( void )
? {
? assert( 0 == 1 ) ;
? }
? EOF
tyger(~)% gcc main.c
main.c: In function ‘main’:
main.c:4: warning: return type of ‘main’ is not ‘int’
tyger(~)% ./a.out
Assertion failed: (0 == 1), function main, file main.c, line 5.
Abort
tyger(~)%
A great big codesplosion spraying you with a several hundred lines of stack trace and a "Your program has encountered an error an needs to close" is not "sensible behaviour".
Yes it is, if it's a program in development where I haven't yet decided what behavior an error condition should produce.
You guys don't seem to understand I don't necessarily want to decide how to handle all errors now, not that I never want to have to think about how to handle them.
http://www.on-time.com/ddj0011.htm
I'm almost tempted to make an analogy with scheme's (call-with-current-continuation) here, but I think that might be pushing it.
This is the fault of the programmer who wrote the function, not of the language.
By the same token, dozens of Java libraries only throw ABCException, with no other information... Might as well be -1.
Whereas when you're dealing with return codes, the default is to ignore.
It seems like a good compromise.
Exceptions are a language semantic - in itself it doesn't make your code robust. You still need to apply it correctly.
But! The reality is the same applies to C too. What the original author was alluding to what that the mentality of C encourages coders to look deeper into their errors.
(Example code is OCaml)
type 'a checked = Pass of 'a | Fail
(* very much a toy example *)
let even x = (x mod 2 == 0)
let can_fail x = match x with
| 0 -> Fail
| x when (even x) -> Pass (x * 10)
| x -> Pass (x)
# can_fail 2;;
- : int checked = Pass 20
# can_fail 3;;
- : int checked = Pass 3
# can_fail 0;;
- : int checked = Fail
#
The author misses the main point of exceptions: they let us separate data processing code from error handling code. This is why we are more productive in languages that have exceptions and our code is easier to maintain.
C requires us to handle errors throughout our program, tightly coupling the data processing code with the error handling code. With apologies to Mr. Spencer, I would declare that:
"Those who don't code in languages that lack exceptions are doomed to reimplement them, poorly."
I honestly don't see any advantage to exceptions over C-style return codes, with one important ...euh... exception: the boiler plate for exception handlers can be well handled by modern IDEs. All the other supposed advantages seem to be just waffling to me. Take the whole 'Oh, but exceptions make handling errors the default!' kind of argument (several examples on this thread already). Yes, sure, you do have to write exception handlers for all errors in a language such as Java. But my experience is that if I'm writing use-once-and-throw-away in C, I'll just not use the return code. In Java I'll just stick a whopping great big try/catch around the whole app, and be done with it. If I'm trying to write stable code that's going to be around for a while in C, I check the error codes returned by a function every single time, which gives me around about as much work as when I am using Java, and actually handling different exceptions correctly.
All of which means, for me at least, that exceptions don't add anything to a language, but they do make the language just a little bit harder to learn (remembering exactly how any given language has implemented exceptions, and which resources can still be safely used when is a pain, as each language tends to have subtle differences that can bite you).
A typical performance issue is calling malloc/free all the time, it can be avoided but there are no standard ways.
I hope some great features of C++ get some day backported to C. But don't bet money on that :(
I tend to see all major projects end up doing things their way: OpenSSL, Apache HTTPd, GCC, Linux, BSD, for example.
Hoard is also suitable for use in real applications: http://www.hoard.org/
Then there's my work, which is frankly not suitable for using in a real application since it's tested as heavily as the other two I mentioned: http://people.cs.vt.edu/~scschnei/streamflow/
But my original point was there is no stantard way. It should be part of CXX, libc, or POSIX, IMHO. C is just too atomized.
Also, I can't edit my post, but that should say "it's not tested as heavily."
[yeah, I guessed you meant that from the sentence structure]
In particular, at startup TCMalloc allocates approximately 6 MB of memory.It's a blind pig with fifteen legs, trying to put on its own lipstick while riding a unicycle.
Well done.
edit: Ignore this post. I misread. I'm an idiot. Sorry about that
C++ template libraries are cleaner, easier to improve and adapt, and often faster than the C counterparts (when there are counterparts!) A good example was how OpenMP was added to the basic types in the STL (on GNU/gcc/libc++) by a quite small group of people last year.
Another example are the regular expression libraries.
I'm not an Stroustroup/C++ apologist but this language is the absolute best in several traits. I like to code in Python the most but C and C++ are still fun and make sense in their own way. I hate languages that make programming hard just because they follow an overcomplicated paradigm and don't give you anything useful back from that (like Java, IMNSHO.) In particular all languages with multi-million dollar advertisement campaign just piss me off (the language, not the tools.)
C has evolved over time, but it has not left its niche: a systems programming language which is a thin abstraction of hardware. If you want a higher abstraction of the hardware, then C is not your best choice.
Also C programs usually are made to run many times and stay alive, so the attitude of the developer tends to be more careful.
Theoretically, high level programming should enable you to focus on the abstractions much more, but somehow it doesn't work this way.
That's not really a bad thing, as the author points out.
One thing I've always felt a sense of dread about in C# and Java (last Java I did was back in 2001) is that I never truly knew what errors were lurking with their exception handling. It would be really nice if all error possibilities were listed in the documentation so I could pick precisely what to handle.
Unchecked exceptions don't seem to be a problem, because oftentimes you don't care what specifically went wrong, you just need to know that something went wrong and abort appropriately.
Yeah, that's a problem - it's a problem of style and implementation rather than a "Java" problem... but it's a problem none-the-less.
Many exceptions in Java are simply == "it didn't work". Often there is no distinguishing between: (a) didn't work because you supplied something invalid (e.g. Integer.parseInt("notanint") and (b) it didn't work, but you can probably recover if you want and (c) it didn't work, there is nothing you can do about it.