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

How can C Programs be so Reliable?

tratt.net

Post reply on HN
Print view View original

91–100 of 105 posts

Re: How can C Programs be so Reliable?

#91

Post by maw »

wheels wrote: post #52
holygoat wrote: post #21

Earlier quoted context omitted.

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 dial…

Interestingly, I noticed earlier this week that the new GCC gives warnings when the return values of POSIX / libc functions are ignored but shouldn't be.

Which versions of gcc and libc? Any special flags passed to gcc? I ask because I just tried it with a test program here (openSUSE Factory, gcc 4.3.3 and glibc 2.8.90) and it didn't print any warnings, but it would be nice if it did.

Re: How can C Programs be so Reliable?

#92

Post by scott_s »

alecco wrote: post #89
scott_s wrote: post #84

Earlier quoted context omitted.

I used to do research with multithreaded memory allocators. The best of class is, I think, TCMalloc, which is a part of Google's perftools: http://code.google.com/p/google-perftools/ . Hoard is also suitable for use in real applications: http://www.hoard.org/ Then there's my work, which is frankly not suitable for using in a real application since it's tested as heavily as the other two I mentioned: http://people.cs.…

Cool! I didn't know Google did a plain C one (thought those were C++) and yours looks interesting. But my original point was there is no stantard way . It should be part of CXX, libc, or POSIX, IMHO. C is just too atomized.

There's a standard interface, but there's no standard implementation - which is how standards generally work.

Also, I can't edit my post, but that should say "it's not tested as heavily."

Re: How can C Programs be so Reliable?

#93

Post by scott_s »

alecco wrote: post #88
scott_s wrote: post #83

Earlier quoted context omitted.

C is, as the author points out, a portable assembly language. If a portable assembly language is not what you need - for example, you want better string support and memory management - then don't use C.

Then why the authors did a standard library from the beginning? (including strings) The problem is it's quite dated (30 years). There isn't anything wrong with the language itself and most languages evolve with time.

Because back when C first was designed and implemented, the alternative was to do string manipulation in assembly.

C has evolved over time, but it has not left its niche: a systems programming language which is a thin abstraction of hardware. If you want a higher abstraction of the hardware, then C is not your best choice.

Re: How can C Programs be so Reliable?

#94

Post by alecco »

alecco wrote: post #89
scott_s wrote: post #84

Earlier quoted context omitted.

I used to do research with multithreaded memory allocators. The best of class is, I think, TCMalloc, which is a part of Google's perftools: http://code.google.com/p/google-perftools/ . Hoard is also suitable for use in real applications: http://www.hoard.org/ Then there's my work, which is frankly not suitable for using in a real application since it's tested as heavily as the other two I mentioned: http://people.cs.…

Cool! I didn't know Google did a plain C one (thought those were C++) and yours looks interesting. But my original point was there is no stantard way . It should be part of CXX, libc, or POSIX, IMHO. C is just too atomized.

Hmmm, not so fast... This is not cool:

  In particular, at startup TCMalloc allocates approximately 6 MB of memory.

Re: How can C Programs be so Reliable?

#95

Post by alecco »

scott_s wrote: post #92
alecco wrote: post #89

Earlier quoted context omitted.

Cool! I didn't know Google did a plain C one (thought those were C++) and yours looks interesting. But my original point was there is no stantard way . It should be part of CXX, libc, or POSIX, IMHO. C is just too atomized.

There's a standard interface, but there's no standard implementation - which is how standards generally work. Also, I can't edit my post, but that should say "it's not tested as heavily."

I was thinking more along the lines of automatic memory in my original grandparent post.

[yeah, I guessed you meant that from the sentence structure]

Re: How can C Programs be so Reliable?

#96

Post by Hexstream »

jodrellblank wrote: post #25
Hexstream wrote: post #13

Earlier quoted context omitted.

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 grace…

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

Yes it is, if it's a program in development where I haven't yet decided what behavior an error condition should produce.

You guys don't seem to understand I don't necessarily want to decide how to handle all errors now, not that I never want to have to think about how to handle them.

Re: How can C Programs be so Reliable?

#97

Post by scott_s »

alecco wrote: post #94
alecco wrote: post #89

Earlier quoted context omitted.

Cool! I didn't know Google did a plain C one (thought those were C++) and yours looks interesting. But my original point was there is no stantard way . It should be part of CXX, libc, or POSIX, IMHO. C is just too atomized.

Hmmm, not so fast... This is not cool: In particular, at startup TCMalloc allocates approximately 6 MB of memory.

Depends on your needs. TCMalloc trades space for speed.

Re: How can C Programs be so Reliable?

#98

Post by scott_s »

alecco wrote: post #95
scott_s wrote: post #92

Earlier quoted context omitted.

There's a standard interface, but there's no standard implementation - which is how standards generally work. Also, I can't edit my post, but that should say "it's not tested as heavily."

I was thinking more along the lines of automatic memory in my original grandparent post. [yeah, I guessed you meant that from the sentence structure]

Then C is not what you're looking for. I'm not arguing against garbage collected languages, but for the necessity of non-GC languages to exist.

Re: How can C Programs be so Reliable?

#99

Post by silentbicycle »

mstevens wrote: post #67
DarkShikari wrote: post #22

Earlier quoted context omitted.

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.

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.

Re: How can C Programs be so Reliable?

#100

Post by orib »

qwph wrote: post #32
alecco wrote: post #30

Earlier quoted context omitted.

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 o…

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 quality thanks to the extra thought put into it. (But I'm only going off vague memories here... I might be misremembering)

Post reply on HN