Man, me too. I feel more comfortable knowing where all my memory is, and that my types are being checked at compile time.

Do you really know where all you memory is being used without Valgrid?

Valgrind should definitely be a part of every C developer's workflow, if possible integrated into the unit and integration tests.

It doesn't help that is isn't available in all platforms, e.g. embedded, real-time OS, commercial UNIXes, mainframes.

That is unfortunate, but in those cases, if C or C++ is the only option, I would advocate writing cross-platform code and running the tests under a Valgrind-supported platform.

This is a bit more difficult for kernel-level code running on an RTOS, as there might be a lot more unique APIs to stub out, but it can still be done.

You are no longer testing the same code under the real execution conditions, thus missing out possible leaks on the original code path.

Although you can add that better test that than nothing, assuming that the respective OS vendor doesn't offer tooling similar to Valgrind, which I fully agree.

EDIT: added some clarifications.

Two of those, embedded and real-time, Valgrind should help very little as you shouldn't be allocating anything anyway apart from statically.

Well, there are still the other pointer misuses that are so common in C code.