Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How can C Programs be so Reliable? (2008)

tratt.net

Post reply on HN
Print view View original

81–90 of 230 posts

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

#81

Post by mhenr18 »

plg wrote: post #37

"Once one has understood a concept such as pointers (arguably the trickiest concept in low-level languages, having no simple real-world analogy) " huh? So when you write a letter to someone, you actually attach their house onto the outside of the envelope? No of course you don't. You write their ADDRESS on the envelope. All this lore about how difficult pointers are, is bunk. The syntax of pointers vs addresses vs de…

Yeah, I've never gotten why people consider pointers to be hard.

If you consider memory to be a massive array, pointers are just the indices that you use to get at different elements in that array.

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

#82

Post by jzwinck »

nitrogen wrote: post #60
clarry wrote: post #43

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

If malloc() fails now, it might succeed again later. So you can just go on doing everything else you were doing, then try the memory-hungry operation again in the future. For example, this could be important in systems where you might be controlling physical hardware at the same time as reading commands from a network. It's probably a good idea to maintain control of the hardware even if you don't have enough memory…

It's an even better idea to make the hardware fail safe, so you can let the program die and not worry too much about it. This does not apply in all cases (cars), but it does apply in many (trains, like a deadman switch for the computer). For a vivid example of why this is an important approach, read about the Therac-25.

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

#83

Post by pux0r3 »

dllthomas wrote: post #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.

I agree with you now. But I keep thinking back ~10 years when seeing a * (or ) was a moment for pause and speculation.

I think it comes down to the address of an int* is a thing, which again makes sense to someone familiar, but to a newcomer means you have a thing at an address that is an address of another thing.

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

#84

Post by vidarh »

RyanZAG wrote: post #19
notacoward wrote: post #7

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…

> Without exceptions this is tougher as you need to unroll everything manually in order to retry.

I don't get why you think this is a problem. You can trivially "unroll" it by explicitly writing your functions to be single-exit and "unrolling" at the end before returning whatever your result is.

"Exception handling" without "real" exceptions is then also trivial: just check the appropriate error code and take whatever action is suitable at the time.

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

#85

Post by [deleted] »

joshguthrie wrote: post #59
Crito wrote: post #26

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

[deleted]

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

#86

Post by waps »

eliteraspberrie wrote: post #33
Crito wrote: post #26

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

The most common way to indicate that an error has occurred in a C function is to return non-zero. If this is done consistently, and return values are always checked, an error condition will eventually make its way up to main, where you can fail gracefully. For example: int a(void) { ... if (oops) { return 1; } return 0; } int b(void) { if (a(...) != 0) { return 1; } return 0; } int main(void) { if (b(...) != 0) { exi…

This is a brilliant example of why you'd want exceptions. Look at what you're doing for error handling, manually every time.

Exceptions do the exact same thing, except: 1) automatically 2) type-safe 3) allow you to give extra detail about the error 4) tools can actually follow the control flow and tell you what's happening and why 5) debuggers can break on all exceptions. Try breaking on "any error" in your code (I do know how C programmers "solve" that : single-stepping. Ugh)

In this case, they are better in every way.

This is almost as bad as the code in the linux kernel and GNOME where they "don't ever use C++ objects !", and proceed to manually encode virtual method tables. And then you have have 2 object types that "inherit" from eachother (copy the virtual method table) and then proceed to overwrite the wrong indices with the overridden methods (and God forbid you forget to lock down alignment, resulting in having different function pointers overwritten on different architectures). Debugging that will cost you the rest of the week.

When it comes to bashing exceptions, it would be better to give people the real reason C++ programmers hate them, it's because of the major unsolvable problem you'll suddenly run in to when using them. In C and C++ you can use exceptions XOR not using exceptions.

This sounds like it's not a big deal, until you consider libraries. You want to use old libraries ? No exceptions for you ! (unless you rewrite them) You want to use newer libraries : you don't get to not use exceptions anymore ! You want to combine the two ? That's actually possible but if any exception library interacts with a non-exception library in the call-stack boom.

Exceptions are a great idea, but they don't offer a graceful upgrade path. Starting to use exceptions in C++ code is a major rewrite of the code. I guess if you follow the logic of the article that "would be a good thing", but given ... euhm ... reality ... I disagree. Try explaining "I'm adding exceptions to our code, rewriting 3 external libraries in the process" to your boss.

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

#87

Post by Scramblejams »

ProAm wrote: post #41
plg wrote: post #37

"Once one has understood a concept such as pointers (arguably the trickiest concept in low-level languages, having no simple real-world analogy) " huh? So when you write a letter to someone, you actually attach their house onto the outside of the envelope? No of course you don't. You write their ADDRESS on the envelope. All this lore about how difficult pointers are, is bunk. The syntax of pointers vs addresses vs de…

Sometimes I just write the contents of their house on the outside of the envelope. You have to admit it is one of the trickier concepts people learn when programming. Once you understand it, it's definitely a "Duh, how else would it work?" moment but getting to that point can take some time.

I agree. The concept may be simple, but when you're just starting out as a C++ newbie and you've got pointers-to-pointers-to-pointers flying all over the place in this ugly syntax trying to satisfy some contrived homework assignment on a short deadline, things can get confusing rather quickly.

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

#89

Post by [deleted] »

azov wrote: post #63

Popular C software is so reliable because of enormous amount of effort spent developing, testing, and polishing it over many years - not because error handling in C is superior to that in higher-level languages. If your python script sticks around for 30 years constantly being used by millions of people - I bet it will be rock solid as well. All other things [1] being equal [2], a program written in a higher-level la…

[deleted]

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

#90

Post by philwelch »

salgernon wrote: post #47
breadbox wrote: post #30

Earlier quoted context omitted.

For a lot of people I think it takes a while to really internalize the ramification of the fact that you can have a pointer to memory you're not allowed to use. (That, plus the way they're used in C as a cheap answer to templates/generics.) I understood that a pointer was an address from the start, but it was still some time before I figured out how to use them correctly.

You've never arrived at a physical address to find a shuttered business or gaping crater? I can understand the syntax of pointers being confusing, but the concept has distinct real world analogies. (That being said, I find the syntax of physical addresses in other countries to sometimes be confusing.)

I've definitely never arrived at an address to find a gaping crater myself.
Post reply on HN