which versions are you using (SonarQube Server / Community Build, Scanner, Plugin, and any relevant extension)
SonarQube Server Version 2025.1, Scanner Version 7.0.1
how is SonarQube deployed: zip, Docker, Helm
zip
what are you trying to achieve
The issue we are having is with a project that contains C and C++. For the C code, there are source files that have the “.c” extension, and header files that have the “.h” extension.
Our local project was scanned using automatic configuration. SonarQube reported several issues on the C code to change all the #defines as constexpr, const, or enum. However, the recommended changes are not legal in C.
If the C code is scanned in its own separate project, SonarQube treats the C code as C sources and not C++ sources. Therefore, all the warnings about the #defines go away.
Is there a way in SonarQube to define sources one way or the other? The “.c” extension should clearly define the file as C and not C++. But the .h extension can be used by either C or C++, which may be complicated.
Hello @lnguyen, and thank you for sharing the issue with us,
For source files, SonarQube Automatic Configuration assigns languages to files by matching the extension with the extensions specified in sonar.c.file.suffixes and the sonar.cpp.file.suffixes (can be changed from the UI in Settings → Languages → C / C++ / Objective-C). The default values for these properties contain what one would expect (e.g. .c is mapped to C files, and .cpp is mapped to C++).
There is one additional exception on top of these properties: If the file has the .C extension (capital c), it is recognized as a C++ file. This follows the convention used in GCC (see here). This means that, by default, files with the .c extension are scanned as C files, whereas files with the .C extension (capital c) are scanned as C++ files.
Header files are analyzed in the context of source files that include them. This means that you would get C++ issues raised on a header once a C++ source file includes it.
Based on the information above and the symptoms you described, I could think of a few possibilities:
The property sonar.cpp.file.suffixes was extended to match .c in your analysis configuration. Changing the property back to the default should fix the problem in that case.
Are C files in your project using the .C extension (with capital c)? If so, they would fall into the exception I described above.
For issues on header files, if one source file that is recognized as C++ includes those header files (either because of 1 or 2), then it is expected to get C++ issues reported on these headers.
Could you confirm if any of the possibilities above apply in your case? Depending on the answer we can try to think of solutions or workarounds.
If not, could you share your full analysis log file with us so that I can take a deeper look at the problem? I can also start a private thread with you if you would prefer not to share these files publicly.