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

71–80 of 97 posts

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

#71

Post by [deleted] »

kaba0 wrote: post #31
nicklecompte wrote: post #8

Earlier quoted context omitted.

> Writing code with the occasional try/catch block isn't too different from writing C and not checking error conditions I think a critical difference is that in C the program is more liable to simply crash if errors aren't correctly handled, whereas in Java/Python/etc the program can just log a stack trace and keep on truckin', even if the bug is actually quite severe. In some cases a crash is preferable - e.g. if so…

So it is worse, therefore it is better? Exceptions are exceptionally good at error handling - they always do the correct default (bubbling up if not handled, bringing a stacktrace with them, and by default they auto-unwrap the correct return value, not making the actual business logic hard to decipher), plus they make error handling possible on as wide scope as needed (try block vs a single return value). I absolutel…

[deleted]

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

#72

Post by neonsunset »

flohofwoe wrote: post #69
neonsunset wrote: post #64

Earlier quoted context omitted.

C# has been focusing on terseness for years now but is kept getting bundled together with Java :(

I'm somewhat aware of the improvements, but at the same time I haven't seen much of that terseness in the real-world C# code I'm dealing with (typically Unity gameplay scripting code).

Unity is stuck on an ancient language version unfortunately and has seen none of the runtime improvements of vanilla .NET due to using custom mono fork and build process. Hopefully this will change with the release of Unity 6. With that said, even old C# can be written in a compact way. Most suffering is completely self-imposed and can even be observed proliferate in languages like Rust with such developers starting to adopt them.

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

#73

Post by xigoi »

flohofwoe wrote: post #53
tored wrote: post #43

Earlier quoted context omitted.

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

Java or C# required me to wrap every piece of code into class boilerplate (I think that has changed in the meantime, but just as an example). In C++, Visual Studio will bombard you with all sorts of silly C++ Core Guideline advice if you try to write simple and straightforward code. Finally, the standard libraries and 3rd party libraries might also get in the way if 'simple and straightforward' clashes with the idiom…

There are other languages than C, Java, C# and C++.

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

#74

Post by xigoi »

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.

Static typing is useless without strict typing. Knowing the type of everything won’t save you if you can multiply a pointer by an integer and use the result as a file handle.

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

#75

Post by oasisaimlessly »

jandrewrogers wrote: post #67
bdw5204 wrote: post #22

Earlier quoted context omitted.

At most, the White House's opinion on C/C++ will impact government contractors and people who care about the White House's opinion on matters it isn't qualified to speak about. I'd only be worried if I were in the business of selling software written in C/C++ to the government but a few campaign donations to politicians would probably get that fixed.

Most interesting parts of US government will buy and consume software written in C++ without qualification or reservation for the indefinite future. People are wishcasting, it isn’t a serious risk. New systems are being planned in C++ today and language choice isn’t even mentioned. Parts of government have a lot of experience with C++ in high reliability contexts. There are many advanced systems in government written…

> Rust is often not a good fit for the software architectures required unless you are comfortable writing a lot of awkward unsafe code.

If you have to write "a lot of awkward unsafe code" in Rust, you're doing something wrong. I use C++ rather than Rust, but any time I'm implementing any sort of non-trivial data structure or inter-thread communication, I encapsulate it in a "safe" interface that is impossible to misuse (at least in debug mode) and clearly deliniates the boundary at which e.g. a memory safety or data race audit would have to cover. In general, minimizing the volume and surface area of "unsafe" code is a generally useful heuristic in any systems language.

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

#76

Post by nicklecompte »

kaba0 wrote: post #31
nicklecompte wrote: post #8

Earlier quoted context omitted.

> Writing code with the occasional try/catch block isn't too different from writing C and not checking error conditions I think a critical difference is that in C the program is more liable to simply crash if errors aren't correctly handled, whereas in Java/Python/etc the program can just log a stack trace and keep on truckin', even if the bug is actually quite severe. In some cases a crash is preferable - e.g. if so…

So it is worse, therefore it is better? Exceptions are exceptionally good at error handling - they always do the correct default (bubbling up if not handled, bringing a stacktrace with them, and by default they auto-unwrap the correct return value, not making the actual business logic hard to decipher), plus they make error handling possible on as wide scope as needed (try block vs a single return value). I absolutel…

> Converse curiously; don't cross-examine. Edit out swipes.

> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize.

> Eschew flamebait. Avoid generic tangents.

In particular you seem to be responding to a strawman, since nowhere did I say C error handling was better than structured exceptions. The parent asked what was functionally different between laziness around checking error codes versus laziness around try/catching.

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

#77

Post by ParetoOptimal »

lelanthran wrote: post #7

I think every graduating student should work on a non-trivial application in plain C for a year before moving on to another language. It makes you exceptionally paranoid about failure states and practically requires a bit of thought and planning before attempting any non-trivial change. The mindset of "it's fine to ignore all error conditions and let the default exception handler print a stack trace to the user" resu…

I think writing in Haskell or Rust and using ADTs and pattern matching with exhaustivity checking does the same thing.

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

#78

Post by yetihehe »

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…

> Then learn an assembly language instead

Learn assembly TOO, not instead. I did, as part of computer architecture course. Very valuable. I think you should learn everything from transistor level up if you want to do serious programming. I don't think you need to actually use it, but it's sometimes very handy to know those things.

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

#79

Post by fanf2 »

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

Static typing is useless without strict typing. Knowing the type of everything won’t save you if you can multiply a pointer by an integer and use the result as a file handle.

Fortunately even C and C++ compilers will complain if you try to do that.

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

#80

Post by BobbyTables2 »

Until one writes a nontrivial program that properly handles -EINTR errors on every possible point, I don’t anyone should brag about their error handing prowess.

It is also hard to handle errors more meaningfully than instantly terminating the process at the first whif of something going sideways.

And once you do write such a thing, try making automated tests to exercise it!!

How many programs actually check the return value of close() ?

Sure, this sounds a bit Linux/POSIX specific. There are only a few billion devises running such code, perhaps I’m overreacting…

Post reply on HN