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

41–50 of 97 posts

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

#41

Post by lelanthran »

lifthrasiir wrote: post #38
lelanthran wrote: post #34

Earlier quoted context omitted.

> While I agree with last two paragraphs, C is not good even for that purpose because it doesn't give any tool to manage them. The "purpose" here is to instill a sense of paranoia around error handling, so that the resulting program from the PoV of the user appears to handle whatever bizarre combination of inputs the user put in. It's the difference between telling the user "Failed to open foo.txt (file not found). D…

> As the article says, checked exceptions are not the solution here. Java had a very bad model of checked exceptions (the OP was written in 2008). A correct way is to make it a part of the type system, though it doesn't have to be a sum type like Rust, and make any error-related code path as convenient as possible to use. > In C, you are forced to perform the NULL-check, or crash. You don't necessarily crash if you f…

> You don't necessarily crash if you failed to perform a NULL check!

In the case of using the result from `fopen`, I don't know of a platform where a dereferencing of NULL (which happens in a separate translation unit, which is already compiled and linked, and will not be subject to LTO and other optimisations) within the various read/write/seek/tell functions doesn't result in an immediate crash.

I fully admit that this is applicable only to this particular example, and to all the functions in the stdlib. Everywhere else (code you wrote, that will be subject to aggressive optimisation, for example), you may not necessarily crash on a NULL dereference.

In the sense of instilling a sense of paranoia, the relative frequency of crashing due to UB is high enough that it does develop the sense of paranoia.

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

#42

Post by flohofwoe »

norir wrote: post #12

C is horrible for exploratory programming but is acceptable if you already know how to solve the problem. If one uses enums for errors, then the compiler can check for you that all edge cases are handled. You can log an error and exit(1) for unhandled cases during development which makes it feasible to turn on -Werror but not have to implement every edge case up front. You can do the same thing with tagged unions to…

> C is horrible for exploratory programming...

Completely opposite experience here. C is great for explorative coding because it's just structs and functions.

There's no agonizing about whether some piece of code should go here or better there, wrapped in this or that concept or high level abstraction.

Instead you start with an empty screen and incrementally build your ideas from small building blocks, much like in Lisp or Forth.

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

#43

Post by tored »

flohofwoe wrote: post #42
norir wrote: post #12

C is horrible for exploratory programming but is acceptable if you already know how to solve the problem. If one uses enums for errors, then the compiler can check for you that all edge cases are handled. You can log an error and exit(1) for unhandled cases during development which makes it feasible to turn on -Werror but not have to implement every edge case up front. You can do the same thing with tagged unions to…

> C is horrible for exploratory programming... Completely opposite experience here. C is great for explorative coding because it's just structs and functions. There's no agonizing about whether some piece of code should go here or better there, wrapped in this or that concept or high level abstraction. Instead you start with an empty screen and incrementally build your ideas from small building blocks, much like in L…

What is stopping you from only using functions and structures in any language?

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

#44

Post by lelanthran »

janalsncm wrote: post #39
lelanthran wrote: post #27

Earlier quoted context omitted.

> Rust is better for this since your program won’t even compile until you’ve handled those error states. How is that better for developing a sense of paranoia around error states? "Throw it at the wall and see what sticks" does not exactly lead to "extreme paranoia managing errors".

This raises the question of whether that extreme paranoia prevents critical errors in code. The fact that so many of the issues still persist suggests it does not. You can tell people to be careful drivers all you want, but what really saves lives is airbags, crumple zones, and seatbelts.

> This raises the question of whether that extreme paranoia prevents critical errors in code. The fact that so many of the issues still persist suggests it does not.

> You can tell people to be careful drivers all you want, but what really saves lives is airbags, crumple zones, and seatbelts.

Could just be that the frequency of repeated accidents (and the related injuries) is too low to instill paranoia. The analogy is not the same as with programming in C, where the frequency is "multiple times a day", and not "less than once in a lifetime.

IOW, I feel that

> The fact that so many of the issues still persist suggests it [extreme paranoia] does not.

is inaccurate.

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

#45

Post by iforgotpassword »

janalsncm wrote: post #39
lelanthran wrote: post #27

Earlier quoted context omitted.

> Rust is better for this since your program won’t even compile until you’ve handled those error states. How is that better for developing a sense of paranoia around error states? "Throw it at the wall and see what sticks" does not exactly lead to "extreme paranoia managing errors".

This raises the question of whether that extreme paranoia prevents critical errors in code. The fact that so many of the issues still persist suggests it does not. You can tell people to be careful drivers all you want, but what really saves lives is airbags, crumple zones, and seatbelts.

Because you can't let a driver crash and have a fatal accident as a lesson. That's what this is about. Make it hard and cumbersome, by having students build something non-trivial. I think another benefit of doing it is the Ikea effect, after you've put some effort into the project and see it come together, you might start caring about it and are motivated to get it to work well. Hopefully then some of that mindset carries over when using high level languages and huge frameworks.

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

#46

Post by bdjsiqoocwk »

begueradj wrote: post #9

The author started by seriously admitting the drawbacks of C. Then, somehow, he says thanks to those flaws he has to pay higher attention when building software in C, he created very reliable tools. That's something I can understand because when I wanted to buy a motorbike I was advised to ride a bicycle first since it's more difficult to control. Except that the White House called recently for companies to not use n…

The white house, the thought leaders in software engineering.

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

#47

Post by lifthrasiir »

lelanthran wrote: post #41
lifthrasiir wrote: post #38

Earlier quoted context omitted.

> As the article says, checked exceptions are not the solution here. Java had a very bad model of checked exceptions (the OP was written in 2008). A correct way is to make it a part of the type system, though it doesn't have to be a sum type like Rust, and make any error-related code path as convenient as possible to use. > In C, you are forced to perform the NULL-check, or crash. You don't necessarily crash if you f…

> You don't necessarily crash if you failed to perform a NULL check! In the case of using the result from `fopen`, I don't know of a platform where a dereferencing of NULL (which happens in a separate translation unit, which is already compiled and linked, and will not be subject to LTO and other optimisations) within the various read/write/seek/tell functions doesn't result in an immediate crash. I fully admit that…

That's a really huge asterisk that wasn't present in your original claim ;-)

> In the sense of instilling a sense of paranoia, the relative frequency of crashing due to UB is high enough that it does develop the sense of paranoia.

Paranoia isn't a cure however. A good programmer will and arguably should develop an instinct to avoid C for most cases instead. I too have written tons of C codes, and yet I feel really uneasy about using C at all. I can't believe that C merely induces the sense of paranoia.

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

#48

Post by flohofwoe »

lifthrasiir wrote: post #35
yetihehe wrote: post #25

Earlier quoted context omitted.

> While I agree with last two paragraphs, C is not good even for that purpose because it doesn't give any tool to manage them. That is the reason it should be used as a learning tool. So that you know the nitty gritty details without anyone "managing" it away from you.

Then learn an assembly language instead, because C also has a fair amount of bookkeeping hidden behind the scene. C is typically described as a "low-level" programming language, where the "low-level" normally refers to the supposed distance from the language to the actual hardware. But as many incidents with UB demonstrate, this distance is still quite larger than expected. I think there is another sense of the word…

This is mostly only true for modern optimising C compilers. If you take a simple C compiler from the 90's, or disable optimisations in a modern compiler, there's a near 1:1 relationship between the C code and compiler output.

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

#49

Post by [deleted] »

cjfd wrote: post #36

I think the reliability gap is in statically typed, compiled languages versus dynamically typed languages. I think C++ is a good combination of both worlds. You don't have to type quite as much for error checking an manual management and you get a correctly typed program by default.

[deleted]

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

#50

Post by tored »

whiterknight wrote: post #15
norir wrote: post #12

C is horrible for exploratory programming but is acceptable if you already know how to solve the problem. If one uses enums for errors, then the compiler can check for you that all edge cases are handled. You can log an error and exit(1) for unhandled cases during development which makes it feasible to turn on -Werror but not have to implement every edge case up front. You can do the same thing with tagged unions to…

> C is horrible for exploratory programming Completely disagree. The lack of screwing around selecting abstractions forces you to make something productive right away and not stress about refactor.

Who is stressing you to refactor when doing exploratory programming? Yourself? OOP languages? Society?
Post reply on HN