# C/C++/Objective-C

*C/C++/Objective-C analysis is available starting in* [*Developer Edition*](https://www.sonarsource.com/plans-and-pricing/developer/)*.*

C/C++/Objective-C analysis is officially registered as [CWE Compatible](https://cwe.mitre.org/compatible/).

## Supported compilers <a href="#supported-compilers" id="supported-compilers"></a>

* Any version of Clang, GCC, and Microsoft C/C++ compilers
* Any version of Intel compiler for Linux and macOS
* ARM5 and ARM6 compilers
* IAR compilers for ARM, Atmel AVR32, Atmel AVR, Renesas H8, Renesas RL78, Renesas RX, Renesas V850, Texas Instruments MSP430, and for 8051
* QNX compilers
* Texas Instruments compilers on Windows and macOS for ARM, C2000, C6000, C7000, MSP430, and PRU
* Wind River Diab and GCC compilers
* Compilers based wholly on GCC including for instance Linaro GCC are also supported

### C++20 <a href="#c20" id="c20"></a>

C++20 support is only partial and offered as-is in SonarQube 8.9 LTS to avoid failing analysis for projects that adopt it. It is not enabled by default. It comes with the following limitations:

* Minimal support for C++20 is provided. Since analysis is based on Clang 12, not all features of C++20 are correctly parsed. See <https://clang.llvm.org/cxx_status.html> for more information.
* Support for this feature is only available through the SonarSource Community; professional support is not available.
* If you need fuller support for C++20, please consider upgrading to the latest SonarQube version. C++20 parsing and rule availability is under ongoing development and will expand in future SonarQube versions.

To enable C++20 support add the property `sonar.cfamily.cpp20` in the *sonar-project.properties* file at the root of your project:

```css-79elbk
sonar.cfamily.cpp20=true
```

## Supported language standards <a href="#supported-language-standards" id="supported-language-standards"></a>

* C89, C99, C11, C18, C++03, C++11, C++14, C++17, and C++20 (partial support) standards
* GNU extensions

## Supported runtime environments <a href="#supported-runtime-environments" id="supported-runtime-environments"></a>

* Microsoft Windows on x86-64
* Linux on x86-64
* macOS with version 10.14.3 and later on x86-64

## Prerequisites <a href="#prerequisites" id="prerequisites"></a>

### Build Wrapper <a href="#build-wrapper" id="build-wrapper"></a>

Analysis of C/C++/Objective-C projects requires the **Build Wrapper**. It runs the build and gathers all the configuration required for correct analysis of C/C++/Objective-C projects (such as macro definitions, include directories, …). The Build Wrapper does not impact your build; it merely eavesdrops on it and writes what it learns into files in a directory you specify.

{% hint style="info" %}
*Build Wrapper* must be downloaded directly from your SonarQube server so that its version perfectly matches your version of the plugin.
{% endhint %}

Substitute the URL of your specific SonarQube instance into the download path below:

* Download *Build Wrapper* for Linux from: \<Your SonarQube URL>/static/cpp/build-wrapper-linux-x86.zip
* Download *Build Wrapper* for macOS from: \<Your SonarQube URL>/static/cpp/build-wrapper-macosx-x86.zip
* Download *Build Wrapper* for Windows from: \<Your SonarQube URL>/static/cpp/build-wrapper-win-x86.zip

Unzip the downloaded *Build Wrapper* and configure it in your `PATH` because doing so is just more convenient.

### SonarScanner <a href="#sonarscanner" id="sonarscanner"></a>

Analysis of C/C++/Objective-C projects requires the [sonarscanner](https://docs.sonarsource.com/sonarqube-server/8.9/analyzing-source-code/scanners/sonarscanner "mention") CLI.

## Analysis steps <a href="#analysis-steps" id="analysis-steps"></a>

* Execute *Build Wrapper* as a prefix to your usual clean build command. A clean build command should always build the project from scratch. The examples below use `make`, `xcodebuild` and `MSBuild`, but any build tool that performs a full build can be used:

```css-79elbk
// example for linux
build-wrapper-linux-x86-64 --out-dir build_wrapper_output_directory make clean all
// example for macOS
build-wrapper-macosx-x86 --out-dir build_wrapper_output_directory xcodebuild clean build
// example for Windows
build-wrapper-win-x86-64.exe --out-dir  build_wrapper_output_directory MSBuild.exe /t:Rebuild
```

* At the end of your build, a *build-wrapper.json* file should be generated in the specified output directory. This file contains information about the translation units that were built by your build command. Any file that doesn’t end-up in a compiled translation unit will not be analyzed. As a consequence, source files that are not compiled and header files that are not included in any compiled source file will not be analyzed. Note that executing build-wrapper doesn’t interfere with your build command. There is no need to build a second time without build-wapper. Just make one build and wrap-it up.
* Add the property `sonar.cfamily.build-wrapper-output` in the *sonar-project.properties* file at the root of your project. You should set it to the path of the *Build Wrapper* output directory relatively to the project directory (`build_wrapper_output_directory` in these examples) Sample *sonar-project.properties*:

```css-79elbk
sonar.projectKey=myFirstProject
sonar.projectName=My First C++ Project
sonar.projectVersion=1.0
sonar.sources=src
sonar.cfamily.build-wrapper-output=build_wrapper_output_directory
sonar.sourceEncoding=UTF-8
sonar.host.url=YourSonarCloud/SonarQubeURL
```

* It is recommended to gather all your code tree in a subdirectory of your project to avoid analysing irrelevant source files like files generated by your build tool. You can specify this subdirectory by setting the property `sonar.sources` accordingly. In this example, we named it `src`.
* Execute the SonarScanner (`sonar-scanner`) from the root directory of your project: `sonar-scanner`\
  For more SonarScanner related options, consult [sonarscanner](https://docs.sonarsource.com/sonarqube-server/8.9/analyzing-source-code/scanners/sonarscanner "mention").
* Follow the link provided at the end of the analysis to browse your project’s quality metrics in the UI.

**Important notes**

* The *Build Wrapper* collects information about the build including absolute file paths (source files, standard headers, libraries, etc…). Later on, SonarScanner uses this information and needs to access those paths. Whereas this is straightforward while running these 2 steps on the same host, it is worth some consideration when using any sort of containerization. A consequence of this is that C / C++ / Objective-C analysis is NOT supported by [SonarScanner CLI Docker image](https://hub.docker.com/r/sonarsource/sonar-scanner-cli).
* The *Build Wrapper* generates the files *build-wrapper.log* and *build-wrapper-dump.json* in its output directory. Both these files contain a dump of the environment. In some contexts, it can be a security concern. Whereas the former is a log file and is not needed for the analysis to run, the latter is needed and cannot be either displaced nor discarded.

## Language-specific properties <a href="#language-specific-properties" id="language-specific-properties"></a>

Discover and update the C/C++/Objective-C specific properties in: **Administration > General Settings > Languages > C/C++/Objective-C**

## Analysis cache <a href="#analysis-cache" id="analysis-cache"></a>

The plugin is able to cache results of analysis and reuse them during another analysis. This has the benefit to speed-up subsequent analysis by analyzing only things that changed between two analyses.

* Enable cache by setting: `sonar.cfamily.cache.enabled=true`\
  `sonar.cfamily.cache.path=relative_or_absolute_path_to_cache_location`\
  Please note that each project should use its own path. To fully benefit from this feature you should configure your CI system to persist the cache path between runs.
* If you prefer to not enable cache and want to turn off the console and UI warnings you should explicitly disable it by setting: `sonar.cfamily.cache.enabled=false`

## Multithreaded Code Scan <a href="#multithreaded-code-scan" id="multithreaded-code-scan"></a>

It is possible to use all the cores available on the machine running the code scan. This can be activated by configuring the property `sonar.cfamily.threads` at the scanner level. Its default value is 1.

* This feature must not be activated on a machine with only 1 core.
* The analyzer will not guess which value is most suitable for your project. It’s up to you to test and find the best value.
* If a build machine with 2 cores is already configured to potentially run two code scans at the same time, there is no guarantee that configuring `sonar.cfamily.threads=2` will bring the expected performance benefits. It can even be worse than running with the default value.
* The multithreaded execution requires more memory than single-threaded execution.
* A machine with 64 cores configured with `sonar.cfamily.threads=64` is not certain to bring a large performance gain compared to a machine with 32 cores. The performance tradeoff will vary depending on the machine, project and setup, so some testing will be required to decide if the performance gain justifies moving to a larger machine.

## Solution with a Mix of C# and C++ <a href="#solution-with-mix" id="solution-with-mix"></a>

When you have a Solution made of C++ and C#, in order to both use the *Build Wrapper* and have an accurate analysis of the C# code, you must use the [SonarScanner for MSBuild](https://github.com/SonarSource/sonar-scanner-msbuild). The SonarScanner for MSBuild does not handle *sonar-project.properties* files so the *Build Wrapper* output directory will have to be set during the MSBuild `begin` step.

Note that in this scenario source code stored in shared folders, not considered as a "Project" by Visual Studio, won’t be scanned.

* Download and install both the [SonarScanner for MSBuild](https://github.com/SonarSource/sonar-scanner-msbuild) and the *Build Wrapper* (see *Prerequisites* section).
* Execute the SonarScanner for MSBuild `begin` step with the *Build Wrapper* output parameter /d:sonar.cfamily.build-wrapper-output=\<build*wrapper*output\_directory>
* Add execution of *Build Wrapper* to your normal MSBuild build command
* Execute the SonarScanner for MSBuild `end` step to complete the analysis

For example:

```css-79elbk
SonarScanner.MSBuild.exe begin /k:"cs-and-cpp-project-key" /n:"My C# and C++ project" /v:"1.0" /d:sonar.cfamily.build-wrapper-output="build_wrapper_output_directory"
build-wrapper-win-x86-64.exe --out-dir build_wrapper_output_directory MSBuild.exe /t:Rebuild
SonarScanner.MSBuild.exe end
```

## Measures for header files <a href="#header-files" id="header-files"></a>

Each time we analyze a header file as part of a compilation unit, we compute for this header the measures: statements, functions, classes, cyclomatic complexity and cognitive complexity. That means that each measure may be computed more than once for a given header. In that case, we store the largest value for each measure.

## Language-specific rule tags <a href="#language-rule-tags" id="language-rule-tags"></a>

On top of the [built-in-rule-tags](https://docs.sonarsource.com/sonarqube-server/8.9/user-guide/rules/built-in-rule-tags "mention"), a few additional rule tags are specific to C/C++/Objective-C rules.

### C++ Standard Version Related Rule Tags <a href="#c-standard-version-related-rule-tags" id="c-standard-version-related-rule-tags"></a>

Some rules are relevant only since a specific version of the C++ standard. These rules will run only when analyzing a C++ code compiled against a later or equal standard version. The following tags are used to mark these rules for the corresponding C++ standard version:

* `since-c++11`
* `since-c++14`
* `since-c++17`

C++ rules not carrying any of these four tags started running since C++98.

### Implementation Related Rule Tags <a href="#implementation-related-rule-tags" id="implementation-related-rule-tags"></a>

* `full-project`: this tag is for rules that do cross translation units analysis. For these rules to work properly, it is important to analyze the entire project. Excluding part of the project from the analysis will impact the accuracy of these rules: it might lead to false-positives or false-negatives.
* `symbolic-execution`: this tag is for rules that reason about the state of the program. They usually work together to find path-sensitive bugs and vulnerabilities. Once a fatal state of the program is reached, one issue will be raised, and the symbolic execution analysis of the current path will stop. For that reason, it is not recommended to evaluate these rules independently of each other as it might give a false sense of undetected issues. It is important to keep in mind that we are always working on improving these rules, as symbolic execution can never be perfect.

## Building with Bazel <a href="#building-with-bazel" id="building-with-bazel"></a>

[Bazel](https://www.bazel.build/) recommends that you use the [`--batch`](https://docs.bazel.build/versions/master/user-manual.html#flag--batch) option when running in a Continuous Build context. When using the *BuildWrapper*, you are in such context. Also, you need to deactivate the ["sandbox"](https://bazel.build/docs/sandboxing) mechanism of *Bazel* so that the compiled file paths could be retrieved after the compilation phase. Here is an example of the *BuildWrapper* command with Bazel parameters on macOS:

```css-79elbk
build-wrapper-macosx-x86 --out-dir bw bazel
  --batch
  build
  --spawn_strategy=local
  --strategy=Genrule=local
  --bazelrc=/dev/null
  //main:hello-world
```

## Related pages <a href="#related-pages" id="related-pages"></a>

* [test-coverage-and-execution](https://docs.sonarsource.com/sonarqube-server/8.9/analyzing-source-code/test-coverage-and-execution "mention") (CPPUnit, GCOV, llvm-cov, Visual Studio, Bullseye)
* [Sample project](https://github.com/SonarSource/sonar-scanning-examples/tree/master/sonarqube-scanner-build-wrapper-linux) for C/C++ (Linux)
* [Sample project](https://github.com/SonarSource/sonar-scanning-examples/tree/master/objc-llvm-coverage) for Objective-C
* [sonarscanner-for-azure-devops](https://docs.sonarsource.com/sonarqube-server/8.9/analyzing-source-code/scanners/sonarscanner-for-azure-devops "mention") (analyzing Visual C++ project)

## Issue tracker <a href="#issue-tracker" id="issue-tracker"></a>

Check the [issue tracker](https://sonarsource.atlassian.net/jira/software/c/projects/CPP/boards/185) for this language.