{"slug": "addresssanitizer", "name": "AddressSanitizer", "category": "other", "category_name": "Other software", "description": "", "recommenders": 7, "commenters": 9, "warners": 0, "score": 6.489, "rising": -0.96, "first": "2025-11-02", "latest": "2026-09-02", "why": "the industry tooling allows you to verify large areas of the program behaviour at runtime (ASAN etc)", "why_is_quote": true, "has_verdict": false, "sentiment": {"recommend": 7, "neutral": 1, "compare": 1, "warn": 0}, "spark": [2, 0, 1, 1, 0, 0, 1, 0, 1, 1, 0, 0], "listed": true, "loved": [], "caveat": "", "short_quote": "the industry tooling allows you to verify large areas of the program behaviour at runtime (ASAN etc)", "kind": "", "icon": true, "domain": "llvm.org", "github_repo": null, "official_url": "https://clang.llvm.org/docs/AddressSanitizer.html", "pricing": "", "aliases": ["AddressSanitizer", "ASan"], "verdict": null, "praise": [{"label": "", "summary": "", "quotes": [{"id": 786444128, "item_id": 49152758, "url": "https://news.ycombinator.com/item?id=49152758", "by": "pg83", "date": "2026-08-03", "version": null, "stance": "recommend", "quote": "asan/ubsan agree with me", "excerpt": "Yes, \"blazingly fast\", but not in Rust! In fact, I have my own development model in C++, which allows me to write at approximately the same level of safety that Rust provides (at least, I think so, and asan/ubsan agree with me) - https://github.com/pg83/std/blob/master/README.md", "context": "", "use_case": "memory bug detection", "switched_from": "", "story": "Show HN: Shitty \u2013 fast terminal. Memory-unsafe and faster than yours"}, {"id": 783650850, "item_id": 48978178, "url": "https://news.ycombinator.com/item?id=48978178", "by": "Ygg2", "date": "2026-07-20", "version": null, "stance": "recommend", "quote": "run this with UBSAN, ASAN, and other C tools", "excerpt": "> Proof: You just listed examples of unbounded lifetimes. > I said \"effectively disable\". For example: Not sure what you meant by this example since it doesn't compile. It seems the borrow checker caught your mischief. So much for effectively disabling stuff :P You haven't effectively disabled anything; you just (tried to) wrote unsound code that washes one mutable ref as another. This stuff is allowed provided share", "context": "", "use_case": "", "switched_from": "", "story": "Claude Code uses Bun written in Rust now"}, {"id": 769079361, "item_id": 48067460, "url": "https://news.ycombinator.com/item?id=48067460", "by": "thangalin", "date": "2026-05-08", "version": null, "stance": "recommend", "quote": "developing a unit test framework based on Catch2 and ASAN that tracks new/delete invocations is rather powerful", "excerpt": "In raw C, I like to use the \"open\"/\"close\" metaphor and when developing, invoke the routes in parallel. For example: https://repo.autonoma.ca/repo/mandelbrot/blob/HEAD/main.c When writing: fractal.image = image_open( fractal.width, fractal.height ); I will immediately write below it: image_close( fractal.image ); This hides memory allocations altogether. As long as the open/close functions are paired up, it gives me ", "context": "", "use_case": "Leak detection", "switched_from": "", "story": "Bjarne Stroustrup: How do I deal with memory leaks?"}, {"id": 750750257, "item_id": 46921891, "url": "https://news.ycombinator.com/item?id=46921891", "by": "nielsbot", "date": "2026-02-06", "version": null, "stance": "recommend", "quote": "testing these projects with ASan enabled", "excerpt": "Wondering how many of these memory errors would be caught by running the Clang Static Analyzer (or similar) on them. https://clang-analyzer.llvm.org Alternatively, testing these projects with ASan enabled: https://clang.llvm.org/docs/AddressSanitizer.html", "context": "", "use_case": "", "switched_from": "", "story": "Evaluating and mitigating the growing risk of LLM-discovered 0-days"}, {"id": 736700016, "item_id": 46043751, "url": "https://news.ycombinator.com/item?id=46043751", "by": "fsloth", "date": "2025-11-25", "version": null, "stance": "recommend", "quote": "the industry tooling allows you to verify large areas of the program behaviour at runtime (ASAN etc)", "excerpt": "I get the feeling author would just like to use a better language, like F# or Ocaml, and completely misses the point what makes C++ valuable. C++ is valuable, because the existing tooling enables you to optimize the runtime peformance of a program (usually you end up with figuring out the best memory layout and utilization). C++ is valuable becaus it's industry support guarantees code bases live for decades _without ", "context": "two decades in CAD, real time graphics and embedded development", "use_case": "runtime verification of C++", "switched_from": "", "story": "Rethinking C++: Architecture, Concepts, and Responsibility"}]}], "caveats": [], "who": [{"by": "fsloth", "context": "two decades in CAD, real time graphics and embedded development", "url": "https://news.ycombinator.com/item?id=46043751", "date": "2025-11-25"}], "tags": [], "use_cases": ["memory bug detection", "leak detection", "catching memory bugs", "runtime verification of c++", "memory checking during qa"], "compared": [{"slug": "undefinedbehaviorsanitizer", "name": "UndefinedBehaviorSanitizer", "co": 3, "switched_from": 0, "switched_to": 0}, {"slug": "miri", "name": "Miri", "co": 2, "switched_from": 0, "switched_to": 0}, {"slug": "fil-c", "name": "Fil-C", "co": 2, "switched_from": 0, "switched_to": 0}], "makers": [{"id": 792807200, "item_id": 49550450, "url": "https://news.ycombinator.com/item?id=49550450", "by": "disconnect3d", "date": "2026-09-03", "version": null, "stance": "recommend", "quote": "I wrote a blog post on it", "excerpt": "In case anyone wants to learn more how ASan works, I wrote a blog post on it at https://blog.trailofbits.com/2024/05/16/understanding-addresssanitizer-better-memory-safety-for-your-code/ It also explains that the fact ASan works well with, e.g., std::vector in C++ doesn't come for free and if you want ASan to detect bugs when your custom collections or allocators are used you have to use special ASan API to mark [in]", "context": "", "use_case": "", "switched_from": "", "story": "GrapheneOS says Pixel 11 has MTE support after all"}], "threads": [{"url": "https://news.ycombinator.com/item?id=49536384", "title": "GrapheneOS says Pixel 11 has MTE support after all", "mentions": 2}, {"url": "https://news.ycombinator.com/item?id=49149326", "title": "Show HN: Shitty \u2013 fast terminal. Memory-unsafe and faster than yours", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=48966569", "title": "Claude Code uses Bun written in Rust now", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=48065916", "title": "Bjarne Stroustrup: How do I deal with memory leaks?", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=46902374", "title": "Evaluating and mitigating the growing risk of LLM-discovered 0-days", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=46588837", "title": "LLVM: The Bad Parts", "mentions": 1}], "sentiment_by_month": {"2025-11": {"recommend": 2, "neutral": 1}, "2025-12": {}, "2026-01": {"recommend": 1}, "2026-02": {"recommend": 1}, "2026-03": {}, "2026-04": {}, "2026-05": {"recommend": 1}, "2026-06": {}, "2026-07": {"recommend": 1}, "2026-08": {"recommend": 1}, "2026-09": {"compare": 1}, "2026-10": {}}, "versions": [], "version_unnamed": 0, "family_ref": null, "runs_on": null, "lines": [], "quotes": [{"id": 792601872, "item_id": 49537617, "url": "https://news.ycombinator.com/item?id=49537617", "by": "delta_p_delta_x", "date": "2026-09-02", "version": null, "stance": "compare", "quote": "MTE is essentially hardware-accelerated AddressSanitiser", "excerpt": "MTE is essentially hardware-accelerated AddressSanitiser[1]. [1]: https://clang.llvm.org/docs/AddressSanitizer.html", "context": "", "use_case": "", "switched_from": "", "story": "GrapheneOS says Pixel 11 has MTE support after all"}, {"id": 786444128, "item_id": 49152758, "url": "https://news.ycombinator.com/item?id=49152758", "by": "pg83", "date": "2026-08-03", "version": null, "stance": "recommend", "quote": "asan/ubsan agree with me", "excerpt": "Yes, \"blazingly fast\", but not in Rust! In fact, I have my own development model in C++, which allows me to write at approximately the same level of safety that Rust provides (at least, I think so, and asan/ubsan agree with me) - https://github.com/pg83/std/blob/master/README.md", "context": "", "use_case": "memory bug detection", "switched_from": "", "story": "Show HN: Shitty \u2013 fast terminal. Memory-unsafe and faster than yours"}, {"id": 783650850, "item_id": 48978178, "url": "https://news.ycombinator.com/item?id=48978178", "by": "Ygg2", "date": "2026-07-20", "version": null, "stance": "recommend", "quote": "run this with UBSAN, ASAN, and other C tools", "excerpt": "> Proof: You just listed examples of unbounded lifetimes. > I said \"effectively disable\". For example: Not sure what you meant by this example since it doesn't compile. It seems the borrow checker caught your mischief. So much for effectively disabling stuff :P You haven't effectively disabled anything; you just (tried to) wrote unsound code that washes one mutable ref as another. This stuff is allowed provided share", "context": "", "use_case": "", "switched_from": "", "story": "Claude Code uses Bun written in Rust now"}, {"id": 769079361, "item_id": 48067460, "url": "https://news.ycombinator.com/item?id=48067460", "by": "thangalin", "date": "2026-05-08", "version": null, "stance": "recommend", "quote": "developing a unit test framework based on Catch2 and ASAN that tracks new/delete invocations is rather powerful", "excerpt": "In raw C, I like to use the \"open\"/\"close\" metaphor and when developing, invoke the routes in parallel. For example: https://repo.autonoma.ca/repo/mandelbrot/blob/HEAD/main.c When writing: fractal.image = image_open( fractal.width, fractal.height ); I will immediately write below it: image_close( fractal.image ); This hides memory allocations altogether. As long as the open/close functions are paired up, it gives me ", "context": "", "use_case": "Leak detection", "switched_from": "", "story": "Bjarne Stroustrup: How do I deal with memory leaks?"}, {"id": 750750257, "item_id": 46921891, "url": "https://news.ycombinator.com/item?id=46921891", "by": "nielsbot", "date": "2026-02-06", "version": null, "stance": "recommend", "quote": "testing these projects with ASan enabled", "excerpt": "Wondering how many of these memory errors would be caught by running the Clang Static Analyzer (or similar) on them. https://clang-analyzer.llvm.org Alternatively, testing these projects with ASan enabled: https://clang.llvm.org/docs/AddressSanitizer.html", "context": "", "use_case": "", "switched_from": "", "story": "Evaluating and mitigating the growing risk of LLM-discovered 0-days"}, {"id": 745538882, "item_id": 46596180, "url": "https://news.ycombinator.com/item?id=46596180", "by": "cogman10", "date": "2026-01-12", "version": null, "stance": "recommend", "quote": "", "excerpt": "Gentoo is calling you ;) https://wiki.gentoo.org/wiki/LLVM", "context": "", "use_case": "", "switched_from": "", "story": "LLVM: The Bad Parts"}, {"id": 737601552, "item_id": 46100097, "url": "https://news.ycombinator.com/item?id=46100097", "by": "steveklabnik", "date": "2025-11-30", "version": null, "stance": "neutral", "quote": "I thought it should too, but it doesn't seem to", "excerpt": "I thought it should too, but it doesn't seem to, unless I made a mistake, which I probably did: https://godbolt.org/z/Ex63vxj4r", "context": "", "use_case": "catching memory bugs", "switched_from": "", "story": "Hardening the C++ Standard Library at scale"}, {"id": 736700016, "item_id": 46043751, "url": "https://news.ycombinator.com/item?id=46043751", "by": "fsloth", "date": "2025-11-25", "version": null, "stance": "recommend", "quote": "the industry tooling allows you to verify large areas of the program behaviour at runtime (ASAN etc)", "excerpt": "I get the feeling author would just like to use a better language, like F# or Ocaml, and completely misses the point what makes C++ valuable. C++ is valuable, because the existing tooling enables you to optimize the runtime peformance of a program (usually you end up with figuring out the best memory layout and utilization). C++ is valuable becaus it's industry support guarantees code bases live for decades _without ", "context": "two decades in CAD, real time graphics and embedded development", "use_case": "runtime verification of C++", "switched_from": "", "story": "Rethinking C++: Architecture, Concepts, and Responsibility"}, {"id": 732715585, "item_id": 45794724, "url": "https://news.ycombinator.com/item?id=45794724", "by": "phire", "date": "2025-11-02", "version": null, "stance": "recommend", "quote": "If you just want memory safety checking during QA, I suspect you are better off sticking with ASan.", "excerpt": "Yeah, it panics when you use after free. [1] But I'm not sure it's worth porting your code to Fil-C just to get that property. Because Fil-C still needs to track the memory allocation with its garbage collector. there isn't much advantage to even calling free. If you don't have a use-after-free bug, then it's just adding the overhead of marking the allocation as freed. And if you do have a use-after-free bug, you mig", "context": "", "use_case": "memory checking during QA", "switched_from": "", "story": "Notes by djb on using Fil-C"}]}