Recommendations for which sanitizers to enable

As time passes, the g++/clang++ gain more new sanitizers, existing ones get better, and some get ported to new platforms (e.g. recently leak support was added to OS X in clang++ 5).

Similar to #37 for warnings, This ticket can serve as a central place to start documenting a recommended list of sanitizer flags to use. I intend this to be a quick, opinionated reference to check before you would dive deeper into docs like https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html.

The relevant questions I see are:

• 🍇 Which sanitizers should we always test with?
• 🍊 Which additional flags or environment variables should we use?
• 🍏 Which additional flags should be used when testing the sanitizers on CI systems?
• 🍎 Which additional flags should be used when building sanitized binaries for live testing?

Refs:

• source of truth for which sanitizers are in which groupings:
  • 4.x: https://github.com/llvm-mirror/clang/blob/release_40/include/clang/Basic/Sanitizers.def
  • 5.x: https://github.com/llvm-mirror/clang/blob/release_50/include/clang/Basic/Sanitizers.def
  • master: https://github.com/llvm-mirror/clang/blob/master/include/clang/Basic/Sanitizers.def
• Docs for HEAD llvm for sanitizers:
• Address: https://clang.llvm.org/docs/AddressSanitizer.html
• Thread: https://clang.llvm.org/docs/ThreadSanitizer.html
• Memory: https://clang.llvm.org/docs/MemorySanitizer.html
• UndefinedBehavior: https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html
• DataFlow: https://clang.llvm.org/docs/DataFlowSanitizer.html
• Leak: https://clang.llvm.org/docs/LeakSanitizer.html
• Control Flow Integrity: https://clang.llvm.org/docs/ControlFlowIntegrity.html
• Safe Stack: https://clang.llvm.org/docs/SafeStack.html

Comience comparando las agrupaciones de sanitizers en los archivos Sanitizers.def referenciados con la documentación de AddressSanitizer, ThreadSanitizer, MemorySanitizer, UndefinedBehaviorSanitizer, DataFlowSanitizer, LeakSanitizer, Control Flow Integrity y Safe Stack. Aclare las recomendaciones para las pruebas siempre activadas, CI y las compilaciones de live-testing, incluidos los flags, las variables de entorno y las limitaciones de la plataforma pertinentes. Se considera terminado cuando el issue contiene una referencia concisa y con una postura clara que cubre esas preguntas.