Live data from Hacker News

How can C Programs be so Reliable? (2008)

tratt.net

11–20 of 230 posts

Re: How can C Programs be so Reliable? (2008)

#11

The author makes a good point about the discipline imposed by not having exceptions. Programmers tend to write code in one of two modes: the quick-and-dirty mode where you consistently don't check return values, or the built-to-last mode where you consistently do. If you start in the first mode and have to fix a bug, you often have to add error checking all up and down the call chain from where it occurs to where it'…

I wonder if that's a general "water seeks its level" thing. We only care so much about robustness, and start to trade off in favor of it at some threshold regardless of language...

Re: How can C Programs be so Reliable? (2008)

#12

The author makes a good point about the discipline imposed by not having exceptions. Programmers tend to write code in one of two modes: the quick-and-dirty mode where you consistently don't check return values, or the built-to-last mode where you consistently do. If you start in the first mode and have to fix a bug, you often have to add error checking all up and down the call chain from where it occurs to where it'…

Yeah, I think that people are starting to realize this. E.g. Go and Rust don't have exceptions (or Java/C++ style exceptions).

Re: How can C Programs be so Reliable? (2008)

#13
post #2

Adjusted for effort I don't know of any evidence that they are...

How does effort affect reliability? Even if you consider one as consequence of the other ("it requires more effort to make a reliable C program than the equivalent program in $language") that doesn't make the final product any less reliable.

It does when you only have a set amount of effort that you can dedicate on a project. Which is usually the case.

Re: How can C Programs be so Reliable? (2008)

#14
"[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.

Re: How can C Programs be so Reliable? (2008)

#15

The author makes a good point about the discipline imposed by not having exceptions. Programmers tend to write code in one of two modes: the quick-and-dirty mode where you consistently don't check return values, or the built-to-last mode where you consistently do. If you start in the first mode and have to fix a bug, you often have to add error checking all up and down the call chain from where it occurs to where it'…

I've been thinking this might be well ameliorated by using checked exceptions, but even languages that have them don't get sophisticated with them, so they wind up being painful enough they're not really used (in my experience).

For instance, I don't know of a language that lets you say "This function accepts a function (f) and returns a function which throws anything f throws except FooException."

Re: How can C Programs be so Reliable? (2008)

#16
post #10

Earlier quoted context omitted.

/x?fnid=KxPuWC6qnkl4nxcUTDh4xs resolves to "unknown or expired link". Do you have a full URL?

It got garbage-collected. That's the point.

Gotcha. The parent comment made it seem like that was a link to information about retrospectively adding GC to other languages, especially given that Lisp already has GC as nearly an assumption at the language level. But I can see what he was trying to get at.

Re: How can C Programs be so Reliable? (2008)

#17

The author makes a good point about the discipline imposed by not having exceptions. Programmers tend to write code in one of two modes: the quick-and-dirty mode where you consistently don't check return values, or the built-to-last mode where you consistently do. If you start in the first mode and have to fix a bug, you often have to add error checking all up and down the call chain from where it occurs to where it'…

Well I think this is only a problem with runtime exceptions. You have no choice but to deal with compile time exceptions (of course you can deal with them poorly if you choose). But it seems the compile time exceptions are unpopular.

I think there's another way to deal with this and that's a better type system. AFAIK it's impossible to have a null pointer exception in Haskell. EG: If you do something like `hashmap.get` the type system forces you to write code to react to the situation when the value doesn't exist in the map. Your code won't run otherwise.

...I can't tell if I'm rambling or replying to you :)

Re: How can C Programs be so Reliable? (2008)

#18
The author's point is weakened by the fact that the Converge VM is now (5 years after this article) written in python: https://github.com/ltratt/converge/search?l=c (as of https://github.com/ltratt/converge/tree/08dadda29b/vm). Compare https://github.com/ltratt/converge/tree/converge-1.x/vm.

"there are some obvious reasons as to why it might be so reliable: it's used by (relatively) large numbers of people, who help shake out bugs; the software has been developed over a long period of time, so previous generations bore the brunt of the bugs; and, if we're being brutally honest, only fairly competent programmers tend to use C in the first place. But still, the fundamental question remained: why is so much of the software I use in C so reliable?"

Why could the fundamental question not be explained by all the points he just mentioned?

I'm a C programmer, and this guy is hitting all my biases, but this isn't very well thought-out.

Re: How can C Programs be so Reliable? (2008)

#19

The author makes a good point about the discipline imposed by not having exceptions. Programmers tend to write code in one of two modes: the quick-and-dirty mode where you consistently don't check return values, or the built-to-last mode where you consistently do. If you start in the first mode and have to fix a bug, you often have to add error checking all up and down the call chain from where it occurs to where it'…

It depends on the problem you're trying to solve, I think.

Let's consider a command line application that fetches a URL, like wget. Without exceptions, you would check the return code of all the system functions you call (dns, sockets, etc), and if any of them fail you can't really recover. You just write out an error message and exit. With exceptions, you could wrap the whole thing and if any system function throws an exception, you print out the exception and exit. So it's much the same in this case.

Now put the url fetch code into a larger application. With exceptions this is pretty easy - you can catch any exception thrown by your url fetch code and then retry it a few times until it succeeds, or you inform the user of the app. Without exceptions this is tougher as you need to unroll everything manually in order to retry.

Finally we have something complicated like running a simulation. If something gives an error, we probably don't want to stop the whole simulation. We'd want to check the specific error result and then fix the simulation and continue. In this case exceptions would add a lot of boiler plate code and would need to be handled just as carefully as error results (eg, wrapping each call in its own try and handling each error).

So it's pretty clear that it depends is very applicable to when you'd rather use exceptions or error results. In general I think exceptions are better as long as they're only used for actual error cases as it gives the user of the functions more control over where and at what level to handle exceptions.

Re: How can C Programs be so Reliable? (2008)

#20
There are idioms and methods for writing reliable C programs, which you learn with experience and reading better code than yours. If you learned languages in the order higher-to-lower, you eventually understand that you cannot write a program in C at the same pace as in a higher level language.

What has worked for me is: always have a second terminal open for the manual pages and the standards; and to regularly read quality C source code. Opengroup.org has thorough references for the standard C library, including its relationship to POSIX and the SUS; and the various kernels and core Unix utilities are always a good read.

Post reply on HN