Two cases for specifying whether files should be treated as headers or sources

Suggest new features
, ,
#1

As far as I understand, sonar doesn’t have a specific mechanism to figure out which files are headers and which files are sources when analyzing c or c++ code.

When using SonarLint that quite often confuses the analyzer when having header files open, causing warnings that are meant for source files.

I now relalized that there’s another case where Sonar emits warnings based on the wrong assumptions about what kind of file it’s analyzing.

Functionally, we have a file that looks like this for the purpose of having code specific for Windows and Unix based systems without mixing it in the same file with mor preprocessor directives than necessary.

#ifdef _WIN32
#include "file_for_windows.cpp"
#else
#include "file_for_unix.cpp"
#endif

Obviously this emits a warning about using #include on a cpp file. We cover that with // NOSONAR. But the bigger challenge seems to be that the analyzer will now treat “file_for_windows.cpp” as a header file because it was included to the translation unit with #include. The effect is that rules such as this can trigger.

It would be convenient to identify files as headers or sources based on the file extensions.

#3

Hello @torgeir.skogen,

For SonarLint we are able to distinguish between the two based on the IDE configuration. Some rules didn’t take this information into consideration which lead to false positives. We recently fixed some of these rules: S831, S958, S1000, S1003, S5318. This is part of CFamily 6.27 that is embedded in SonarLint for Visual Studio 5.0 and 6.1 for CLion.
If you still face some false positives in SonarLint please report them separately and we will fix them.

For SonarQube and SonarCloud, you are right we do consider every included file as a header file. In the end, "file_for_windows.cpp" is used as a header file. At the same time, I see the value of such a feature, so let’s see if it gets enough traction to prioritize on our side.

Thanks,