When i run sonar-scanner on my C-code i get thousands of false positive warnings for the rule ID:c:S125 Sections of code should not be commented out for comments that are definitely no code.
For example the following code:
/* !FOO BAR, 1 */
/* !FOO BAR.baz, 1 */
The first line is not considered as code an does not produce a warning, while second line is considered as code and produces a false positive.
Can you please provide more information how you detect c-code and if this rule can be configured.
Disabling the rule is not an option for us, since it is part of MISRA-C.
Unfortunately, the heuristics used in this rule are not easy to describe. The main idea is to classify each token in the comment as leaning toward it being code or natural language, building a confidence score about the nature of the comment.
This classification does not consider tokens in isolation, but in context (< has some chances of being code, but not if followed with >. A ; at the end of a line is more suspect than in the middle…).
And more heuristics are put on top of it, for instance a doxygen-like code block inside comments clearly introduces some code, but this code is not commented-out code, it is a code snippet inside a documentation.
The comments in your example may not be code, but they are not natural language either, which explains the heuristics fail in your case. Do you have some flexibility in the way you write them?
If you write them in a way that is recognized as doxygen-like stuff, for instance by starting the line with @, they will not be reported.
The comments are indeed not natural language, but they are not code either. They are formal comments intended for another tool.
Regarding changing the comments, there are two issues:
First, it is not clear what they should be changed to in order to satisfy the rule.
Second, we are dealing with several tens of thousands of comments that would need to be modified and reviewed, which would represent a significant amount of work. Switching to Doxygen-style comments would also introduce problems on the Doxygen side.
Is there perhaps a configuration option available for this rule?
Anyway, I would expect that only actual code is classified as code. Formal comments that are neither natural language nor executable code seem to be a valid use case that should not trigger this warning.
For your first point, starting the line with @ would work. I however understand your second point.
!FOO BAR, 1 could be actual code within the right context. Since commented-out code usually gets stale, we did not want to consider as commented-out code only text that could actually compile, but any text that could reasonably be considered as code.
For the moment, this rule does not allow configuration. I created a ticket to add some. However, can you share which tool are you using that requires these formal comments? In addition to configuration, we might want to add direct support for this tool if that can be of value for all our users.
I still struggle to see a realistic C context in which !FOO BAR, 1 would represent valid code.
As far as I can tell, for this expression to become valid C, FOO would have to be a macro that expands to nothing. While technically possible, that seems like a highly artificial and extremely uncommon use case rather than something that would occur in real-world code.
In practice, this pattern is far more likely to appear in configuration files, command syntax, data formats, or documentation than in actual C source code.
From my perspective, requiring users to justify every C or non-C syntax pattern is less practical than providing a configurable opt-out mechanism for the “commented-out code” detection. Such an option would be simpler to maintain, more transparent for users, and would avoid false positives in environments where comments legitimately contain non-C-like or even C like content for cases where the comment contains for example usage examples.
Therefore, I still believe this report reflects a false positive rather than a meaningful detection of commented-out C code.
There are other options, but I agree macros would indeed have to be part of it. I should have put quotes around “reasonable”. Your example is slightly more likely to be code than natural language, but not by far.
As I said, I agree and created a ticket to add such a mechanism.
I still would appreciate (if possible, and if it is an external tool) to know which tool require the comment format you use, to be able to provide first class support for it.