Do they? Mature C code: yes. Modern one: no, many times affected by using very bad algorithms...
How can C Programs be so Reliable?
81–90 of 105 posts
Re: How can C Programs be so Reliable?
#82Earlier quoted context omitted.
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?) :)
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 people that uniform.
The directory structure and file names are straightforward. Want to know where the main scheduling code is? kernel/sched.c. What about the data structures for scheduling? include/linux/sched.h. How is fork implemented? kernel/fork.c. This is important because it means the source is discoverable.
Functions are just the right length. A single function conceptually does one thing, as it should. I've never read through a function and thought "This should be factored out into several different functions."
Consistent and intuitive names. Even if I've never read a function, or seen the definition of a variable, I have a good idea of what it does just by the name. This is should be true for all code, but considering the size and complexity of the code, I find it impressive I've never thought "That's a stupid name." It helps that special functions follow certain naming conventions. For example, if I encounter a function named do_foo(), I know that it is the function called for a foo system call.
And most importantly, any time I've wanted to know how something works in the Linux kernel, I've always been able to figure it out with focused study and tracing. Focused study, not a heroic effort. If it takes longer than I thought it would, it's always because I had to learn a few new concepts along the way, not because the code was obtuse.
Reading the Linux kernel code helps if you do it using LXR, http://lxr.linux.no/, which does a cross-reference of the code. Most variable names, functions and structures are links to their definitions and occurrences.
Re: How can C Programs be so Reliable?
#83The 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 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.
Re: How can C Programs be so Reliable?
#84Earlier quoted context omitted.
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.
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.vt.edu/~scschnei/streamflow/
Re: How can C Programs be so Reliable?
#85Earlier quoted context omitted.
if ((result = foo()) == -1) { fprintf(stderr, "!$*!$&^!$*!!!!\n"); exit(1); }
If exit() is too abrupt, you can always use setjmp() and longjmp() to set up a non-local jump to an error handler.
Agreed. I rarely exit() out of an error. I was responding to the parent's want for "a big, flashy, loud, total failure".
Re: How can C Programs be so Reliable?
#86This 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…
You seem to forget that in embedded systems, C is still the most used language. So most of the new systems developed these days have new C code. And embedded systems are everywhere. Also a big part of embedded systems have to be reliable for years in hostile environement without external interventions. so I wouldn't say that this is easily predictable subsystems.
Can depend on what the code is embedded in.
C has been gaining traction in embedded avionics software, which is purposefully very simple, understandable, maintainable code, and tested & verified beyond nearly any other type of software.
C is also used on mobile phones, where it's more hit & miss, as I'm sure many of us have experienced first-hand...
Re: How can C Programs be so Reliable?
#87As a person who spent few years doing C programming, and then got trapped into the Ruby realm, I must say that the main difference is focus. If you have to focus about memory management, strings, you think much more about the code you write.
Theoretically, high level programming should enable you to focus on the abstractions much more, but somehow it doesn't work this way.
Re: How can C Programs be so Reliable?
#88The 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 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.
Re: How can C Programs be so Reliable?
#89Earlier quoted context omitted.
Like? (No sarcasm.) I tend to see all major projects end up doing things their way: OpenSSL, Apache HTTPd, GCC, Linux, BSD, for example.
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.
Re: How can C Programs be so Reliable?
#90Earlier quoted context omitted.
Please elaborate why you think that. (e.g. style, interdependencies, or maybe compared to something?) :)
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!