Recommendations for which sanitizers to enable

Open
#41 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Documentation
Clarity
Needs clarification
Activity status
Stale
Tech stack
cpp

Research direction

Start by comparing the sanitizer groupings in the referenced Sanitizers.def files with the AddressSanitizer, ThreadSanitizer, MemorySanitizer, UndefinedBehaviorSanitizer, DataFlowSanitizer, LeakSanitizer, Control Flow Integrity, and Safe Stack documentation. Clarify recommendations for always-on testing, CI, and live-testing builds, including relevant flags, environment variables, and platform limits. Done means the issue contains a concise, opinionated reference covering those questions.

Written by the indexing model from the issue text.

Description

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:

Dominant language
No language data
Stars
110
Forks
17
PR merge metrics
No merged PRs in 30d

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from mapbox/cpp

All issues in mapbox/cpp

Similar issues

More Documentation issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.