This only works if you don't stray too far away from the "typical" C. But a lot of large projects written in C will have tons of extensions and modifications making tools like Valgrind irrelevant.
For instance, I worked in a company that rolled its own coroutines in a way very similar to how they work in Go on top of many other things they did to the language runtime. Valgrind couldn't "understand" what was happening in that runtime at all and if you tried to run it would spew millions of warnings (similar problem you'd have if you used Bohem GC with your C program).
There was a way to "teach" Valgrind to understand what was going on in that runtime, but and even though we tried, at some point we realized that it would take too much effort to do so.
I'd bet that OPs home-made alloca() would have a similar effect on Valgrind too.
I was only trying to defend the article author from the accusation of hubris. If all of these tools are indeed used until they show no errors at all, not even false positives (as the article claims), and if the test suite used to run them is non-trivial, then they are likely far more secure than a typical program written in Rust or even something like Go or C# or Java (which all allow and internally use raw pointer manipulation for things like interop).
For instance, I worked in a company that rolled its own coroutines in a way very similar to how they work in Go on top of many other things they did to the language runtime. Valgrind couldn't "understand" what was happening in that runtime at all and if you tried to run it would spew millions of warnings (similar problem you'd have if you used Bohem GC with your C program).
There was a way to "teach" Valgrind to understand what was going on in that runtime, but and even though we tried, at some point we realized that it would take too much effort to do so.
I'd bet that OPs home-made alloca() would have a similar effect on Valgrind too.