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.
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 =(
> We are proposing the name EfficiencySanitizer, or "esan" for short, to
refer to this suite of dynamic instrumentation tools for improving program
efficiency. As we have a number of different tools that share quite a bit
of their implementation we plan to consider them sub-tools under the
EfficiencySanitizer umbrella, rather than adding a whole bunch of separate
instrumentation and runtime library components.
> While these tools are not addressing correctness issues like other
sanitizers, they will be sharing a lot of the existing sanitizer runtime
library support code. Furthermore, users are already familiar with the
sanitizer brand, and it seems better to extend that concept rather than add
some new term.
Is the advertisement value really worth this abuse of "sanitizer"? This is not a sanitizer.
7 comments
[ 3.5 ms ] story [ 26.3 ms ] threadAfter 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.
https://gcc.gnu.org/onlinedocs/gcc-5.3.0/gcc/Debugging-Optio...
> While these tools are not addressing correctness issues like other sanitizers, they will be sharing a lot of the existing sanitizer runtime library support code. Furthermore, users are already familiar with the sanitizer brand, and it seems better to extend that concept rather than add some new term.
Is the advertisement value really worth this abuse of "sanitizer"? This is not a sanitizer.