AddressSanitizer
No written verdict yet. Here is what commenters said.
7recommend
0warn against
Nov 2, 2025first mention
Sep 2, 2026latest mention
Why people recommend it
“asan/ubsan agree with me”
“run this with UBSAN, ASAN, and other C tools”
Show 3 more
“developing a unit test framework based on Catch2 and ASAN that tracks new/delete invocations is rather powerful”
“testing these projects with ASan enabled”
“the industry tooling allows you to verify large areas of the program behaviour at runtime (ASAN etc)”
two decades in CAD, real time graphics and embedded developmenton “Rethinking C++: Architecture, Concepts, and Responsi…”
Caveats and dissent
No one in these comments warned against it.
Often compared with
Who recommends it in their own words
From the makers not counted in the ranking
“I wrote a blog post on it”
Threads where it came up
- GrapheneOS says Pixel 11 has MTE support after all 2 mentions
- Show HN: Shitty – fast terminal. Memory-unsafe and faster than yours 1 mention
- Claude Code uses Bun written in Rust now 1 mention
- Bjarne Stroustrup: How do I deal with memory leaks? 1 mention
- Evaluating and mitigating the growing risk of LLM-discovered 0-days 1 mention
- LLVM: The Bad Parts 1 mention
Also written as ASan. Data: addresssanitizer.json. Quotes are verbatim; the verdict and theme labels are written by a model from these comments, and every clause links to its sources.
All comments 9
“MTE is essentially hardware-accelerated AddressSanitiser”
“asan/ubsan agree with me”
“run this with UBSAN, ASAN, and other C tools”
“developing a unit test framework based on Catch2 and ASAN that tracks new/delete invocations is rather powerful”
“testing these projects with ASan enabled”
Gentoo is calling you ;) https://wiki.gentoo.org/wiki/LLVM
“I thought it should too, but it doesn't seem to”
“the industry tooling allows you to verify large areas of the program behaviour at runtime (ASAN etc)”
“If you just want memory safety checking during QA, I suspect you are better off sticking with ASan.”