4 ms·
The existing sanitizers are awesome. Since they are based on runtime instrumentation and not static analysis, essentially all of the problems are real and acti
by chubot 11y ago
The existing sanitizers are awesome. Since they are based on runtime instrumentation and not static analysis, essentially all of the problems are real and actionable.
After I used them to find a lot of real bugs, the great advantage of LLVM's modular architecture dawned on me. I had read this chapter before, but it honestly seems a bit bland and general... http://www.aosabook.org/en/llvm.html http://www.aosabook.org/en/llvm.html
But when you see it in action, you know that LLVM is a huge advance over the state of the art. Looking forward to the efficiency sanitizers too.
- brian-armstrong 11y agoUsing ASan feels like using the C I always wanted but never had
- optforfon 11y agoThey've also really made emacs a very viable IDE using rtags/irony + cmake. It's a real shame the GNU ecosystem has fallen behind b/c it's really mature, integrated with system tools and also modular (just not as module) - and I'm stuck using it if I want to target embedded =(
- mpercy 11y agoRun your tests against clang (as well as gcc) and then ship with gcc. Last I heard, gcc still had the speed advantage for optimized code anyway.
- teddyh 11y agoGCC has AddressSanitizer (including the Linux Kernel AddressSanitizer), ThreadSanitizer, LeakSanitizer and UndefinedBehaviorSanitizer: https://gcc.gnu.org/onlinedocs/gcc-5.3.0/gcc/Debugging-Options.html#index-fsanitize_003daddress-648 https://gcc.gnu.org/onlinedocs/gcc-5.3.0/gcc/Debugging-Optio...