How can C Programs be so Reliable? • Hacker News Board

Re: How can C Programs be so Reliable?

#101

Post by qwph » Thu, Nov 13, 2008, 1:28 AM UTC

orib wrote: post #100

qwph wrote: post #32

Earlier quoted context omitted.

The stability of any system is roughly proportional to how much automated testing is done against it.

Or how much thought goes into it. 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…

That's not an exclusive or though. If you have a proof of your code's correctness, I'd still like to see it being regressed against any changes to the code. Ideally the more different methods you have for validating that your code is doing what it's supposed to be doing, the better.

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.

Re: How can C Programs be so Reliable?

#102

Post by alecco » Thu, Nov 13, 2008, 1:44 AM UTC

alecco wrote: post #90

scott_s wrote: post #82

Earlier quoted context omitted.

First, I'll grant that there's very little internal documentation. This hurts. But I find I can still figure out what's going on by reading the code, and that the really obtuse things have comments. 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 peop…

Cool, thanks!

[Edit] LXR doesn't have call links or graph. It helps but only a bit (it can be done with egrep on command line.)

Re: How can C Programs be so Reliable?

#103

Post by orib » Thu, Nov 13, 2008, 4:08 AM UTC

qwph wrote: post #101

orib wrote: post #100

Earlier quoted context omitted.

Or how much thought goes into it. 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…

That's not an exclusive or though. If you have a proof of your code's correctness, I'd still like to see it being regressed against any changes to the code. Ideally the more different methods you have for validating that your code is doing what it's supposed to be doing, the better. 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 do…

Of course it doesn't make software worse, but you make it sound like it's the only factor in software quality. Far from it, and IMO the degree to which it has become a religion is disturbing. I suspect that might be the source of the downmods.

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.

Re: How can C Programs be so Reliable?

#104

Post by qwph » Thu, Nov 13, 2008, 5:42 AM UTC

orib wrote: post #103

qwph wrote: post #101

Earlier quoted context omitted.

That's not an exclusive or though. If you have a proof of your code's correctness, I'd still like to see it being regressed against any changes to the code. Ideally the more different methods you have for validating that your code is doing what it's supposed to be doing, the better. 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 do…

Of course it doesn't make software worse, but you make it sound like it's the only factor in software quality. Far from it, and IMO the degree to which it has become a religion is disturbing. I suspect that might be the source of the downmods. 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 us…

Yeah, if you have more tests than actual code, that would seem to indicate something's gone wrong somewhere. And I'd agree that no amount of testing is going to turn an O(n) algorithm into an O(log n) one. There's no substitute for sitting down with a pen and paper and doing some old fashioned design sometimes.

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

Re: How can C Programs be so Reliable?

#105

Post by mstevens » Tue, Dec 09, 2008, 4:07 PM UTC

silentbicycle wrote: post #99

mstevens wrote: post #67

Earlier quoted context omitted.

But you have to actively decide to ignore it. Whereas when you're dealing with return codes, the default is to ignore.

In OCaml, you're required to do something with the return from any non-void function. You can just say "ignore (f x)" to discard the result, so it's not hugely inconvenient, but causes suspect code to accumulate warning signs. It seems like a good compromise.

This also seems like a pretty good strategy. I really need to take that OCaml book off the shelf.