Live data from Hacker News

How can C Programs be so Reliable?

tratt.net

21–30 of 105 posts

Re: How can C Programs be so Reliable?

#21
post #8

Earlier quoted context omitted.

The only time a function would "silently" return a -1 would be if you're not checking your returns for errors! Functions have return codes for a reason .

But oftentimes I want a correct result or an obvious failure, without having to handle tons of errors I don't even want to account for.

Returning -1 is an obvious failure.

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.

Re: How can C Programs be so Reliable?

#22

Earlier quoted context omitted.

You don't need an exception mechanism to deal with this - good libraries will let you find out the exact condition (if you do get a -1 for example). By the same token, dozens of Java libraries only throw ABCException, with no other information... Might as well be -1.

But you can't ignore the ABCException, your app will crash. If you ignore the -1, then you're app will happily continue on doing something wrong.

Sure you can ignore it. You don't want to know the number of times I've seen people using the "try, catch, toss away the exception" structure in Java code.

Re: How can C Programs be so Reliable?

#23
post #2

The author has a unique perspective since he - somehow - skipped learning C until now. He programmed assembly before, and from his other work he clearly is familiar with dynamic and more modern languages. 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 language…

I'm still not convinced that there's anything particularly magical about C here. Reliable programs are written by people who:

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

Re: How can C Programs be so Reliable?

#24
post #23
post #2

The author has a unique perspective since he - somehow - skipped learning C until now. He programmed assembly before, and from his other work he clearly is familiar with dynamic and more modern languages. 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 language…

I'm still not convinced that there's anything particularly magical about C here. Reliable programs are written by people who: * 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 choic…

The author comes to a similar conclusion.

Re: How can C Programs be so Reliable?

#25

Earlier quoted context omitted.

if ((result = foo()) == -1) { fprintf(stderr, "!$*!$&^!$*!!!!\n"); exit(1); }

That won't scale. I'm sure you'll have lots of fun grepping through your source files looking for "!$ !$&^!$ !!!!" when it appears on your stderr. The point is that with an exception system you don't have to write stupid shit like that everywhere just to crash and burn correctly. 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 c…

From what breif comments I've read on Lisp's condition system, it sounds much better. Containing and isolating the error, as soon as possible, then passing information about the error higher up like an exception might propagate, until a level high enough to know the goal of the operation and what to do in case of errors, then passing a response back down, and being able to continue in a useful manner or tidy up gracefully.

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

Re: How can C Programs be so Reliable?

#26

Earlier quoted context omitted.

You don't need an exception mechanism to deal with this - good libraries will let you find out the exact condition (if you do get a -1 for example). By the same token, dozens of Java libraries only throw ABCException, with no other information... Might as well be -1.

But you can't ignore the ABCException, your app will crash. If you ignore the -1, then you're app will happily continue on doing something wrong.

Well I don't know your experience, but most Java developers I've seen either throw the exception, or suppress it... If they throw it, it eventually ends up as ABCGenericException and you've probably got no chance to reasonably recover. If you suppress it you end up with a nasty side effect (a null somewhere perhaps) that causes the app to bomb in another unexpected piece of code.

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.

Re: How can C Programs be so Reliable?

#27

If, as in the case of extsmail, one wants to be robust against errors, one has to handle all possible error paths oneself. 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 l…

> It would be really nice if all error possibilities were listed in the documentation so I could pick precisely what to handle.

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.

Re: How can C Programs be so Reliable?

#28
post #6

If, as in the case of extsmail, one wants to be robust against errors, one has to handle all possible error paths oneself. 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 l…

It's even worse. For top level functions it can throw the UNION of the exceptions thrown by the functions it calls. Therefore, by changing a low level function's exception signature the exception signature of all higher level functions changes too. That always worried me, but it's doesn't seem to be a big deal in practice.

It's a huge deal with checked exceptions in Java. You have to change the signature of every caller, and so on, when you change a low-level function. Abstraction leakage galore; it's why many libraries just throw a single generic exception type whenever anything goes wrong (which defeats the purpose of exceptions) or subclass RuntimeException (which defeats the purpose of checked exceptions).

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.

Re: How can C Programs be so Reliable?

#29
Programs compiled from C don't change much when run, while dynamic applications vary significantly on every run due to the large environment (e.g. GC.) This is a bliss for debugging. I've never seen anything like gdb on any other language. You can backtrack, set and change things, watch for expressions, and even run one line of compiled code at a time to see what's breaking.

Also C programs usually are made to run many times and stay alive, so the attitude of the developer tends to be more careful.

Re: How can C Programs be so Reliable?

#30
post #2

The author has a unique perspective since he - somehow - skipped learning C until now. He programmed assembly before, and from his other work he clearly is familiar with dynamic and more modern languages. 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 language…

that was my experience when I went from ASM - to functional and then C when wrangling hardware. I am still surprised at how reliable C apps can be (linux kernel) - hats off to the genii involved in making things stable.

I use Linux, but I am still surprised it is really stable. At low level it's quite messed up and shows the cons of being a pseudo-bazaar ecosystem. Lately it's changing to a cathedral with a handful of core developers acting quite dictatorial and perhaps that will clean up things a bit. I'm not advocating any of both camps, just bringing up it is far from perfect.

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.

Post reply on HN