http://btorpey.github.io/blog/2014/03/27/using-clangs-addres...
Article mentions JVM noise, but my actual experience is with python noise. Good riddance; this is going into my CI test suite today.
j/k, though I've fixed memory bugs, overflow, use after free, etc. written by people much smarter than me. without static analyzers, valgrind, and afl its possible that some would still exist nearly a decade later.
Also, any custom C++ allocator is going to contain a bunch of unsafe code too.
It's true that a C++ custom allocator will have lots of "unsafe" code, but this is really where C++ shines. The tooling is more complete, the aliasing rules are better documented and understood, the language fights you less, the stdlib has explicit support, it is easier to control the codegen. Rust cannot bring its strengths to bear on this sort of problem.
In fairness, the next sentence in the post is:
> Techniques like this can be a nice complement to external tools like Valgrind or AddressSanitizer.
> Over the years, I’ve wasted many hours debugging memory issues. With just a hash table and a set of linked lists, you can track the history of all your allocations. That makes it pretty easy to track down use after free errors, double free errors, and memory leaks. Using guard pages around your allocations, you can detect overflows.
No, just use address sanitizer–it's meant for this. Odds are your custom allocator might have a few bugs in itself and they will make you life more annoying if you're trying to use it for only this.