News for hackers. Stuff that matters.
Re:Llvm-Dev RFC: Efficiency Sanitizer by chubot on Tuesday April 19, 2016 @01:16AM (#11525024)
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

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.

Re:Llvm-Dev RFC: Efficiency Sanitizer by brian-armstrong on Tuesday April 19, 2016 @03:22AM (#11525370)
Using ASan feels like using the C I always wanted but never had
Re:Llvm-Dev RFC: Efficiency Sanitizer by optforfon on Tuesday April 19, 2016 @06:25AM (#11525990)
They'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 =(
Re:Llvm-Dev RFC: Efficiency Sanitizer by teddyh on Tuesday April 19, 2016 @07:23AM (#11526170)
GCC has AddressSanitizer (including the Linux Kernel AddressSanitizer), ThreadSanitizer, LeakSanitizer and UndefinedBehaviorSanitizer:

https://gcc.gnu.org/onlinedocs/gcc-5.3.0/gcc/Debugging-Optio...

Re:Llvm-Dev RFC: Efficiency Sanitizer by mpercy on Tuesday April 19, 2016 @06:33AM (#11526016)
Run 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.