Why is that a shame? Instead of including a tool like this on every single program invocation (which is essentially what happens if the language forced array bounds checking and other things) you only do it when you need to.
It's a perfect split - do this when developing the program, and not when running the program.
When you are doing the edit/compile/run cycle of developing you should always run via valgrind. It has options to make it silent except if there are errors so it's not annoying.
If you are running your program normally and only using valgrind sometimes for an extra check you are doing it wrong.
It's a shame because in other languages, if there's a bug in my program which goes uncaught, it won't create a massive security vulnerability or a segfault.
You can protect against that by running your vulnerable program in a VM without large performance loss. However, you cannot easily bring your heavily-checked/cache-inefficient/no-inlining Java/Javascript/Python program up to the same C/C++ speed.
This is not a dig against these languages, rather a justification why people are still using C/C++.
Valgrind can only catch bugs that are exposed while the program is running under it. In most cases (when you have a good testsuite), this is sufficient. However, especially in the case of security vulnerabilities, you might have a bug that is only exposed on specific or malformed input that non of your testsuites check for. For example, if you are parsing input from an untrusted source, and that input has a length prefixed field. Unless your testsuite includes a message whose length prefix is longer than the actual length, Valgrind will not tell you that you will potentially overflow, because you do not do so in any of your tests.
Comments
Why is that a shame? Instead of including a tool like this on every single program invocation (which is essentially what happens if the language forced array bounds checking and other things) you only do it when you need to.
It's a perfect split - do this when developing the program, and not when running the program.
When you are doing the edit/compile/run cycle of developing you should always run via valgrind. It has options to make it silent except if there are errors so it's not annoying.
If you are running your program normally and only using valgrind sometimes for an extra check you are doing it wrong.
i.e.
Bounds checking is "essentially" binary instrumentation? That's an... interesting claim.
It's a shame because in other languages, if there's a bug in my program which goes uncaught, it won't create a massive security vulnerability or a segfault.
You can protect against that by running your vulnerable program in a VM without large performance loss. However, you cannot easily bring your heavily-checked/cache-inefficient/no-inlining Java/Javascript/Python program up to the same C/C++ speed.
This is not a dig against these languages, rather a justification why people are still using C/C++.
There is no language in the world which, in general, prevents bugs becoming security vulnerabilities.
Yes, but certain specific types of security issue are impossible in other languages.
People say that and it's not true. Any bug that can be caught by a change in the language can also be caught by valgrind.
And if you are still worried about bugs, you can use -fsanitize=....
Valgrind can only catch bugs that are exposed while the program is running under it. In most cases (when you have a good testsuite), this is sufficient. However, especially in the case of security vulnerabilities, you might have a bug that is only exposed on specific or malformed input that non of your testsuites check for. For example, if you are parsing input from an untrusted source, and that input has a length prefixed field. Unless your testsuite includes a message whose length prefix is longer than the actual length, Valgrind will not tell you that you will potentially overflow, because you do not do so in any of your tests.
I understood all that, that's why I mentioned -fsanitize
Which only works in two C compilers that aren't available in all OS out there.