Some good points in the essay but I have to admit that for me the reason I like C is that it's the first language I ever really did any serious programming in and the first language that made me think hard. Because of that it just feels like home when I come back to it and I can never really evaluate it without that bias. Its the simplest model of the machine that you can get without going down to assembly. Its the same reason I like riding and fixing bicycles. In both cases sparse resources have kept the design to the bare minimum.
How can C Programs be so Reliable? (2008)
71–80 of 230 posts
Re: How can C Programs be so Reliable? (2008)
#72Earlier quoted context omitted.
What's the point of propagating all errors way up to main if you're only going to exit anyway? I think we know how to indicate errors in C functions. What to do about specific errors, in this case allocation failures, is a more interesting question.
To make sure you free() all your previous allocations on the way down. You can choose not too, it's "kinda" the same (can't remember the exact difference) but it's dirty and people with OCD just won't accept it. (Disclosure: I got OCD too, this is not meant to make C development hostile to people with OCD.)
If your program is going to exit anyway, there's no need to call free() on allocated memory. The operating system will reclaim all of the memory it granted to your process when it exits. Remember that malloc lives in your process, not the kernel. When you ask for memory from malloc, it is actually doling out memory that you already own - the operating system granted it to you, when malloc requested it. And malloc requested it because you asked for more memory than it was currently managing.
If your intention is to continue running, then of course you want to call free() on your memory. And this certainly makes sense to do as you exit functions. But if you're, say, calling exit() in the middle of your program, for whatever reason, you don't need to worry about memory.
Other resources may be a problem, though. The the operating system will reclaim things it controlled, and granted to your process - memory, sockets, file descriptors and such. But you need to be careful about resources not controlled by the operating system in such a manner.
Re: How can C Programs be so Reliable? (2008)
#73Earlier quoted context omitted.
> Needless to say, calling exit() when a call to malloc() failed wasn't an acceptable recover routine. What do you do when malloc fails? A bit of graceful shutdown and logging seems like it would be in order, but otherwise how do you keep rolling if mallocs start failing? It seems to me like that would indicate something has gone unusually wrong and full recovery is futile.
Go ahead. Call exit(). On your HTTP/IRC/anything server. Just because you couldn't allocate memory for one more client. Now your service is down and the CTO is looking for blood =) Yes, it's far-fetched and like some said further down the comments, you "can't" run out of memory in Linux, but straight killing a service is never good.
I'd say letting that server bounce and having the watchdog/load balancer work to keep you at capacity is the best option there. You are going to need that infrastructure anyway and if you can't malloc enough for one more client, who is to say that the existing stuff is going to be able to continue either?
You should count on any particular instance bouncing when that happens, and design your system to survive that. You should also invest some effort to figure out why your system can get into that state. Consider if any particular instance should be attempting to accept more jobs than it has the ability to handle. I shouldn't be able to trigger an out of memory situation on your IRC server just by connecting as many irc clients as I can.
Re: How can C Programs be so Reliable? (2008)
#74Earlier quoted context omitted.
I don't get the sense that there was any attempt to recover from errors - it sounds more like they were enforcing that error checking occurred, by replacing `malloc` with one that just returned `NULL` always. It sounds like the goal was to make sure that one didn't assume `malloc` would always succeed and just use the memory. Indeed, recovery is basically futile in this case and your program is going to shut down pre…
What if you application is the fly-by-wire for an airliner? Can you imagine that there might be better options than just calling abort(3)?
From what I understand, in those sort of absolutely critical applications the standard is to design software that fails hard, fast, and safe. You don't want your fly-by-wire computer operating in an abnormal state for any amount of time, you want that system to click off and you want the other backup systems to come online immediately.
The computer in the Space Shuttle was actually 5 computers, 4 of them running in lockstep and able to vote out malfunctioning systems. The fifth ran an independent implementation of much of the same functionality. If there was a software fault with the 4 main computers, they wanted everything to fail as fast as possible so that they could switch to the 5th system.
Re: How can C Programs be so Reliable? (2008)
#75It is an interesting observation. I have found that scripted languages are unreliable as a function of loadable modules (which is to say they depend on some module that gets loaded, that at some point changed, and then broke the script). C has that problem too with shared libraries but there are generally fail stop policies in place (if you can't get the version you were linked against exit rather than try to valiant…
> I have found that scripted languages are unreliable as a function of loadable modules (which is to say they depend on some module that gets loaded, that at some point changed, and then broke the script).
That's why I'm thankful for a lot of these newfangled virtual environments and machines along with their respective package managers (and why more people should use them!).
Re: How can C Programs be so Reliable? (2008)
#76Because those of us who have been doing it for 15 years or more know we're tangling with tigers and have figured out how to use their strength against them...
Re: How can C Programs be so Reliable? (2008)
#77"[Pointers are] arguably the trickiest concept in low-level languages, having no simple real-world analogy[.]" I'm not sure how "address" is not a good, "simple real-world analogy" for pointers. It may be that I've just internalized enough of the behavior of pointers that I'm glossing over important differences, though... I struggled with pointers long enough ago that I don't remember struggling with pointers.
They are so simple. It's just the address of the thing it points to.
Maybe it's lost in the mists for me too, but if you don't know your pointers from yout references from your values... how can you code anything?
Re: How can C Programs be so Reliable? (2008)
#78Earlier quoted context omitted.
What if you application is the fly-by-wire for an airliner? Can you imagine that there might be better options than just calling abort(3)?
Embedded systems like this do not use dynamic memory allocation.
Ugh that's why I'll never buy Boeing; non-upgradable memory in 2013? Please!
Re: How can C Programs be so Reliable? (2008)
#79Earlier quoted context omitted.
What if you application is the fly-by-wire for an airliner? Can you imagine that there might be better options than just calling abort(3)?
Embedded systems like this do not use dynamic memory allocation.
Related: The JPL C guidelines forbid dynamic memory allocation: http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf (HN discussion: https://news.ycombinator.com/item?id=4339999)
They also demand that code be littered with sanity checking assertions.
Re: How can C Programs be so Reliable? (2008)
#80I should note that less experienced programmers tend to start with higher level languages, as a rule, so the average experience of a C programmer is likely higher than that of the HLL programmer. This general experience level alone gives the resulting code a reliability boost.
With notable exceptions, I think this is true. I've been coding seriously for 2 years and am starting to move down the stack. I see others in my cohort doing the same thing.