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

51–60 of 105 posts

Re: How can C Programs be so Reliable?

#51

Post by lhorn »

jwilliams wrote: post #42
lhorn wrote: post #37

Earlier quoted context omitted.

So? Despite being useful, what's so interesting about CRUD programming for the enterprise? I've been there, I've had my share of dealing with coworkers that openly admit that they haven't touched a single book since graduation 10 years ago and they see no reason why would they want to. That's the kind of programmers this industry attracts, and that's the kind of software it builds. What's so interesting about it? Why…

> My ex-wife with zero programming experience has trained herself in less than a month to run a simple SQL queries in Visual basic and blast results in a grid control on a form, so did thousands of ex-taxi drivers in late 90s. So? To be honest, I'm still not sure what point you're trying to make is. At best it's somewhat of an Ad Hominem attack.

I am arguing against this line:

"People often write in higher level languages because they want lots of bad code fast."

Even if this is true, it's true only in enterprise software environment where code quality has never been terribly important. Therefore it can't really be an argument against higher level languages in the context of a typical HN discussion.

Makes sense?

Re: How can C Programs be so Reliable?

#52

Post by wheels »

holygoat wrote: post #21
Hexstream wrote: post #12

Earlier quoted context omitted.

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

Re: How can C Programs be so Reliable?

#53

Post by wheels »

This misses two points I consider important:

- A whole lot of C code is old. Old, actively maintained code, tends to be more reliable than new code.

- C tends to be employed in relatively predictable sub-systems. Something like a device driver has a relatively predictable set of states relative to a GUI application. There aren't that many paths. C code for GUIs, in my experience, tends to be at least a buggy as code in other languages.

Re: How can C Programs be so Reliable?

#54

Post by LogicHoleFlaw »

jmtulloss wrote: post #48
qwph wrote: post #19

Earlier quoted context omitted.

If exit() is too abrupt, you can always use setjmp() and longjmp() to set up a non-local jump to an error handler.

setjmp/longjmp is essentially what exception handlers do for you. I love C for its simplicity, but I'm not certain that leaving exception handling out of the language was a good idea. There are a lot of people who would agree with me there, including (I believe) a few Bell labs veterans who wrote the language in the first place.

The nice thing about exceptions beyond setjmp/lngjmp (in C++ at least) is the destructor semantics which you can use to guarantee that resources are cleaned up on error. There are better ways to handle such things, such as scoped resource allocation, but exceptions do an ok job.

Re: How can C Programs be so Reliable?

#55

Post by alecco »

holygoat wrote: post #38
alecco wrote: post #31

The problem with C is they left too many things completely on the wild. Strings and memory management are all laissez-faire and everybody does whatever they think is right. A typical performance issue is calling malloc/free all the time, it can be avoided but there are no standard ways. I hope some great features of C++ get some day backported to C. But don't bet money on that :(

The later C standards add additional features. However, I'd argue that there is no such thing as a "great feature" in C++: almost everything in the language is a mistake, either intrinsically or in combination with other 'feature's. It's a blind pig with fifteen legs, trying to put on its own lipstick while riding a unicycle.

The language is quite overcomplicated, yes. But there are many mitigations making the whole thing quite appealing.

C++ template libraries are cleaner, easier to improve and adapt, and often faster than the C counterparts (when there are counterparts!) A good example was how OpenMP was added to the basic types in the STL (on GNU/gcc/libc++) by a quite small group of people last year.

Another example are the regular expression libraries.

I'm not an Stroustroup/C++ apologist but this language is the absolute best in several traits. I like to code in Python the most but C and C++ are still fun and make sense in their own way. I hate languages that make programming hard just because they follow an overcomplicated paradigm and don't give you anything useful back from that (like Java, IMNSHO.) In particular all languages with multi-million dollar advertisement campaign just piss me off (the language, not the tools.)

Re: How can C Programs be so Reliable?

#56

Post by alecco »

liuliu wrote: post #35
alecco wrote: post #31

The problem with C is they left too many things completely on the wild. Strings and memory management are all laissez-faire and everybody does whatever they think is right. A typical performance issue is calling malloc/free all the time, it can be avoided but there are no standard ways. I hope some great features of C++ get some day backported to C. But don't bet money on that :(

C believes that programmer doesn't make mistakes. About memory management, I don't think it should be a language feature because there are some good implemented libraries out there.

Like? (No sarcasm.)

I tend to see all major projects end up doing things their way: OpenSSL, Apache HTTPd, GCC, Linux, BSD, for example.

Re: How can C Programs be so Reliable?

#57

Post by rglullis »

lhorn wrote: post #51
jwilliams wrote: post #42

Earlier quoted context omitted.

> My ex-wife with zero programming experience has trained herself in less than a month to run a simple SQL queries in Visual basic and blast results in a grid control on a form, so did thousands of ex-taxi drivers in late 90s. So? To be honest, I'm still not sure what point you're trying to make is. At best it's somewhat of an Ad Hominem attack.

I am arguing against this line: "People often write in higher level languages because they want lots of bad code fast." Even if this is true, it's true only in enterprise software environment where code quality has never been terribly important. Therefore it can't really be an argument against higher level languages in the context of a typical HN discussion. Makes sense?

No, it doesn't.

I'm in no way trolling here, but if you think about it, most of the guys working on startups are also producing lots of bad code fast. The only difference is that most of them are aware of it, and will improve the code based on the requirements from the market.

Re: How can C Programs be so Reliable?

#58

Post by qwph »

LogicHoleFlaw wrote: post #54
jmtulloss wrote: post #48

Earlier quoted context omitted.

setjmp/longjmp is essentially what exception handlers do for you. I love C for its simplicity, but I'm not certain that leaving exception handling out of the language was a good idea. There are a lot of people who would agree with me there, including (I believe) a few Bell labs veterans who wrote the language in the first place.

The nice thing about exceptions beyond setjmp/lngjmp (in C++ at least) is the destructor semantics which you can use to guarantee that resources are cleaned up on error. There are better ways to handle such things, such as scoped resource allocation, but exceptions do an ok job.

You can actually use setjmp()/longjmp() to implement that kind of thing, it turns out. Here's but one example:

http://www.on-time.com/ddj0011.htm

I'm almost tempted to make an analogy with scheme's (call-with-current-continuation) here, but I think that might be pushing it.

Re: How can C Programs be so Reliable?

#59

Post by alecco »

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.

It should be, but usually it is just user base. Microsoft has the advantage of everybody sweating hard trying to make their things work. Their beta users are in the millions, and mostly are experienced users or even developers.

I see Linux developers talk about regression tests but couldn't find where is the central repository of this (is there one?) Regression tests IMHO should be distributed with the source code so everybody can run them. (I understand testing a kernel is not like testing any other user space program.) The BSDs do it, for example.

Re: How can C Programs be so Reliable?

#60

Post by alecco »

scott_s wrote: post #36
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…

In contrast, I consider the Linux kernel code clear and clean. I have mostly looked through the scheduling and file system code; I can't speak for TCP/IP port management.

Please elaborate why you think that. (e.g. style, interdependencies, or maybe compared to something?) :)
Post reply on HN