Leif, we've reached the maximum reply depth here, which I guess means that we need to finish this up. I don't think there are people who can't use valgrind, but

Leif, we've reached the maximum reply depth here, which I guess means that we need to finish this up. I don't think there are people who can't use valgrind, but it just doesn't give you all that much. It lets you know that there aren't memory problems in the execution paths that you hit with your test files. But you can't test your program with every possible input; say you wrote some server - are you going to test it with every possible internal state and every combination of connections and all possible data coming over those connections? You can't. It's a gigantic search space. You can try to guess the likely problem inputs, but that's an art, not a science. Now, malware teams use their experience/intelligence and tools (fuzzers) to find combinations of inputs that will fail your program. You won't always win a race with them - finding vulns is their only focus and main expertise. I don't see how valgrind will stop them. They'll find configurations that valgrind never saw. The real world will also find inputs that break your program; in this case, there is just no malice. If you run valgrind and see a clean report and say "great, no memory problems then", then you've been lulled into a false sense of security. Part of my background is in software verification, and it's never this simple even for stricter and simpler languages than C/C++. Also, I've been involved in projects in which valgrind specifically provided tons of frustration by reporting false errors - in particular, it "didn't like" the implementation of STL which we were using, and gave us errors on half the STL allocations. This was very many years ago, and it's been improved since then, but I guess I don't have a personal experience which makes me want to trust everything valgrind tells me. But that's completely secondary to the issue of not seeing all possible execution paths.