Tools only created to solve the lack of safe constructs in C.

C made lots of sense in the context it was developed, but the world would be better if we had safer systems programming languages.

Valgrind, purify and friends are required to C, the same way Java requires IDEs, to improve language usability.

Have said this, the new trend in having static analysis tools integrated in the development process, like Clang, Eclipse CODA, Visual Studio's tools or HP Code Advisor, among others, can bring a bit more safety into C.

C is popular, good enough, portable, and fast. Skilled C programmers do not need profilers, bounds checkers and memory leak detectors. They help some people, though, no doubt. When size and speed matters, as in Operating Systems, C has won and continues to win the survival of the fittest competition. Almost all the programs I use are C (and/or C++): bash, linux, perl, firefox, awk, sed, grep, apache, mysql, etc. I assume good chunks of Java are written in C, but I'm not sure.

We have "safer" languages but our systems and tools remain in C. Given the intense competition in software, there must be solid reasons C remains the foundation of computing.

I'm with you on the advantages of C, but this is not true:

"Skilled C programmers do not need profilers, bounds checkers and memory leak detectors."

Skilled programmers use profilers because the alternative (guessing) is a poor strategy for diagnosing poor performance. And no skilled programmer would spurn a useful tool like a bounds checker or memory leak detector, because nobody is perfect and these tools save immense amounts of time by pointing you straight to the problem.

Not need profilers? I haven't run into a C (or any other language) programmer so skilled that he's even usually correct at finding the bottleneck without a profiler.

Programmers who don't use profilers write slow programs (even though they spend many hours "optimizing" them).

By that metric, here's a list of non-skilled programmers:

- Donald Knuth (wrote a study on profilers)

- Rob Pike (wrote a profiler, 'though for FORTRAN)

- Brian Kernighan (used a profiler to double the speed of his AWK interpreter)

I wonder who you consider a skilled C programmer, if not K from K&R.

> ... Skilled C programmers ...

Sadly you don't find many of them in the enterprise world, specially when dealing with off-shoring companies. :(

> ... Given the intense competition in software, there must be solid reasons C remains the foundation of computing.

Because it is dumb to code everything new, just because another language is cooler, nicer, safer, etc. So existing software keeps being coded in C.

Even if I expressed my opinion the way I did, I will surely pick C if it makes sense for the project at hand.

In the case of C safer also means weaker and less useful, it is a language where you need to be able to do everything. In some way C is "Assembler-complete". With valgrind you have no compromises, because you have a specialized runtime giving you control over what happens only at debugging time.

There is lots of great discussion going on in this thread. I particularly enjoyed the article, which took a "deliberately novice" approach, and was very Zen-like.

Why attack C at all? Why not instead convince us of the merits of another language?

There are great tools around. I agree with that. Which parts of Clang do you like best?

The static analyser, friendlier error messages and the plugin architecture that allows it to integrate easily in IDEs.

The re-factoring support and modules extensions are also a welcome additions.

Absolutely. Also the gcc mudflap library, splint static checker, Torvald's sparse have really helped.

And that's without the commercial tools such as Coverity.

Valgrind has almost single handedly rescued C from the ashheap of history.

This is why Zed pushed it so hard in Learn C the Hard Way.

Some people actually had the gall to complain about him ensuring the noobies learned to use valgrind before proceeding to write any real code.

Ingrateful dipshits don't remember what the pre-valgrind/dtrace days were like.

Is Learn C the Hard Way a useful re-introduction? Like the article, I need to re-learn C.

Last time I wrote anything in C was on Netware NLMs, and it has been long enough that I have mostly forgotten what I knew.

i was looking for a good book to bring me up-to-date on recent changes to c and the best suggestion i received was to get the latest edition of harbison and steel's book (which includes c99).

i don't know if you know the book - an older copy is on my desk and it use it regularly when working in c - but it's part introduction and part informed guide to the libraries. it's not a "friendly" book (it's not for "dummies"), but it's well written and surprisingly compact for all it contains (at least, the copy i have is; i am waiting for delivery of the latest version).

Yes.

Depends what you mean by "proper". Any fool can get a C program to work, but ensuring there are no memory leaks etc is very hard without a tool like Valgrind.

If you don't believe me, just run Valgrind on random sampling of C programs that didn't use such a tool - I reckon it will find issues with most of them.

Valgrind (and tools using its methodology) isn't the only way to solve these problems. Libumem finds memory leaks too, and without imposing an immense runtime cost. It also finds many types of memory corruption without the runtime overhead that often changes the program's behavior that you're trying to debug.

Agreed. Valgrind can be very helpful, saved me few times. You know huge modular application, one line bug, dead end situation. Too bad output is mess, ups, full of details :-)

One can always write proper C programs without Valgrind: it is "just" a (really useful) debugging tool. The utility of it is that instead of spending days trying to track down any mallocs missing frees, one can just run Valgrind to find them and their locations straight away.

I guess what my grandparent said, albeit in a slightly dismissing tone, is that relying on tools like Valgrind or Purify to produce good code makes for weak programmers. The days spent trying to track down missing frees can be reduced to hours with practice, and the programmer skilled in this hunt is less likely to forget the free in the first place. (As opposed to the programmer relying on Valgrind and not caring much when writing the code the first time).

I do not necessarily abide by this point of view, but I do respect the kind of harsh discipline it advocates. Valgrind is definitely useful, really useful, but great C programs (and programmers) existed long before it appeared.

You should not be worried about this: even with valgrind a few bugs will take days of debugging to get fixed...

Even with Valgrind, I can't believe our industry has ever produced a single great C program. Certainly not Linux or TeX or GCC, all of which I've seen crash yet still had to use because everything else is even worse. Software engineering is still at the leeches-and-evil-spirits stage of maturity, and the continued use of platforms like C (where very common constructs can cause undefined behavior) is a symptom.

you write bug-free code? please, tell me more.

Yes, please, write proper C without Valgrind so I have to spend my time fixing all the memory corruption issues in it =)

The advantage of not feeling tied to valgrind is that you don't need to run your program under valgrind to get the benefit of whatever mechanisms are in place to detect scribbles, accesses to uninitialised data, and leaks.

(valgrind's lack of availability is a bit of a problem. I'm not complaining - I bet it is a bit fiddly to port it to a new system - but it's very easy to never have come across any system that can run it in your professional life. So being able to work without it is no waste of time.)

Uninitialised data and memory scribbles can be tricky to detect 100% reliably without valgrind, but if you code appropriately, you'll spot it. Leaks are very easy to find (fixing them, not always so much), and I don't really understand why one needs this monster program to discover them - but maybe one day I'll actually be in a position to use it, and I'll find out what I'm missing.