valgrind, is only available for a few platforms/architectures.
If you are unable to writer proper C programs without valgrind's help, please go home. :-)
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.
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.
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.
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.