% cat foo.c
    #include <stdio.h>
    int *bad(void) { int a = 42; return &a; }
    int main(void) { int *p = bad(); printf("%d\n", *p); return 0; }
    % gcc foo.c
    foo.c: In function ‘bad’:
    foo.c:2:30: warning: function returns address of local variable [enabled by default]

    % cat bar.cc
    #include <iostream>
    #include <vector>
    
    using std::vector;
    using std::cout;

    void bar(vector<int *> &v) {
        int a = 42;
        v.push_back(&a);
    }

    int main(void) {
        vector<int *> v;
        bar(v);
        cout << *v[0];
        return 0;
    }
    % g++ bar.cc
    % valgrind --track-origins=yes ./a.out
    ...
    ==8210== Conditional jump or move depends on uninitialised value(s)
    ==8210==    at 0x4EBAFE4: std::ostreambuf_iterator<char, std::char_traits<char> > std::num_put<char, std::ostreambuf_iterator<char, std::char_traits<char> > >::_M_insert_int<long>(std::ostreambuf_iterator<char, std::char_traits<char> >, std::ios_base&, char, long) const (in /usr/lib/libstdc++.so.6.0.16)
    ==8210==    by 0x4EBB305: std::num_put<char, std::ostreambuf_iterator<char, std::char_traits<char> > >::do_put(std::ostreambuf_iterator<char, std::char_traits<char> >, std::ios_base&, char, long) const (in /usr/lib/libstdc++.so.6.0.16)
    ==8210==    by 0x4EC62BC: std::ostream& std::ostream::_M_insert<long>(long) (in /usr/lib/libstdc++.so.6.0.16)
    ==8210==    by 0x400B98: main (in /home/leif/a.out)
    ==8210==  Uninitialised value was created by a stack allocation
    ==8210==    at 0x400B78: main (in /home/leif/a.out)
    ...

And of course we use valgrind and a bunch of other standard and custom tools. I said myself that valgrind will help here, so it's not like you need to read me the whole kindergarten primer on this.

Of course valgrind and friends have false positives, but in other languages where these errors are compile errors, you can't suppress them when you need to, instead, you just can't write that code, even if you've been alerted to the issue and know it's ok.

Of the software teams I do know, every one that was writing C/C++ (including my current one) incorporated valgrind and other tools into their build/test framework, and had no problems separating signal from noise. I don't know that many though, I'm still young. Do you know of software teams developing critical software that are unable to check their C code for memory errors automatically?

Anyway, problem #1 is that valgrind is not a code-coverage tool - it only sees the execution path that just happened. You can, of course, combine it with a code-coverage tool, and people do, but code coverage is an incredibly difficult thing, since a huge number of code paths just don't happen in any normal execution. And those are the dangerous ones, both for malware attacks and for reliability.

Problem #2, which is smaller, is that valgrind is just not that perfect - for real-life code with foreign-language interfaces, real-time driver accesses, and so on and so on, it will give false positives and false negatives. This is why it has a feature where it takes a humongous error-suppression file to stop it from showing you things that you're not interested in. That's not a perfect solution.

I'm not saying there is nothing you can do - of course you can, and for well-defined projects with strong security goals and very large resources, you can get to excellent security. But even the Sun JVM had buffer overflows, I seem to remember. Those guys have heard of valgrind.

If there was a button that someone could push to make C/C++ lack of memory safety stop mattering, it would have been pushed by now.

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.

Why not fuzz your own code then?

Yes, you need to fuzz your code, but that's not a simple process; you need to give fuzzers very complicated information about the possible problem input for your program. And there is no reason to think that your team is better at searching for vulnerabilities than a malware team; you're in a race.

Yeah, it's not perfect, but nothing we have is. I don't know what more to say. It works pretty well for most things I've seen. Do you have any examples of projects which can't use something like valgrind for some reason, not just those for which it wasn't magic pixie dust?