2

The title says it all... I have project which needs to MISRA 2004 clean, and the company was told CodeSonar was a good tool to do the static analysis.

On other static analysis tools you can add a magic comment to disable analysis for the next line\block of code, (PC-Lint is //lint -esym(42), CStat uses #pragma cstat_suppress="MISRAC++2008-6-4-1") but CodeSonar doesn't appear to have any equivalent - please tell me I'm wrong!

I've seen mention of a // NOSONAR but that does not appear work on CodeSonar 5.1

(I'm rapidly coming to the conclusion CS is a pile junk written by people who have never programmed in the real world with SVN and multiple programmers, where disabling warnings in a fancy UI goes down the swanny when you're merging branches into trunk and all the line numbers change.)

Anonymouse
  • 935
  • 9
  • 20
  • You can't fix the warning? That's always the best way to get rid of a warning. Also, if you have some way to specify line numbers to ignore, write simple script which searches the code for some magic comments, and adds the line numbers to ignore. – hyde Sep 15 '19 at 11:40
  • 1
    MISRA warnings can be VERY picky about code, so it's normal to suppress some warnings on a specific line, the same warning somewhere else could be genuine so you fix it. A script is perhaps something worth looking into. – Anonymouse Sep 15 '19 at 12:17
  • "Fixing" the warning is not possible in my case as it's a false positive. – Penghe Geng Oct 04 '19 at 21:42
  • Fyi Not fixing is Ok, but not documenting or storing this information in a review artifact is not Ok. –  Dec 03 '20 at 13:56

2 Answers2

2

Since CodeSonar 4.0.0, there is a new filter option added to WARNING_FILTER: line_content that allows you add a "magic comment".

Add the following line to your proj_name.conf:

WARNING_FILTER += line_contents:"NOLINT"

This will disable warnings for a line ending with // NOLINT

Penghe Geng
  • 13,286
  • 5
  • 31
  • 40
1

Check out the documentation and examples for configuration variable WARNING_FILTER.

CodeSonar doesn't provide an out-of-the-box // NOSONAR in any version. However, one of the available rule forms for WARNING_FILTER will allow you to implement one for yourself if that is the approach you decide to take.

If you need to suppress a specific warning, you should be able to annotate the warning directly. The signatures that are used to correlate 'the same' warning between analyses do not depend on line number or other code features that are highly likely to change.

ACG
  • 11
  • 3
  • Since you're a new user, and this is the first question you've "answered" I assume you're in some way affiliated with CodeSonar\GammaTech -- it would be nice if you declared your interest... I will investigate what you say about WARNING_FILTER's. – Anonymouse Oct 03 '19 at 10:05
  • 1
    I work for GrammaTech, but am not answering in an official capacity. My interest is in helping, since nobody else had. This is not a frequent SO occurrence in areas I know well - so infrequent that in a decade or so of use I didn't need an ID until yesterday. Also, don't forget you have access to CodeSonar support and to the customer community. (This may also be why you aren't getting answers from other CodeSonar users, or seeing many questions from them.) – ACG Oct 03 '19 at 13:10
  • 1
    I did try support, but they were less than helpful - basically saying "this is a silly idea and old-fashioned idea. Nobody would ever want such feature. We're not going to implement, it. Use the web interface!" - completely missing the point we have to send source code to an external approval authority, with their own analysis tools, and telling them to cross reference a Sonar config file is not wash. – Anonymouse Oct 04 '19 at 08:19
  • Given your description, my reading is that you have two separate but related issues: 1) you need to be able to account for your false positive designations to some third party; 2) a third party will be running one or more unspecified tools over your codebase. I will address these in separate comments for readability's sake. – ACG Oct 04 '19 at 13:13
  • For 1) one option is to do the following: a) use the warning annotation functionality to mark false positives directly, and at the same time add a freeform note explaining your justification; b) when it comes time to hand over to the approval authority, create a CodeSonar report that lists all your marked false positives and includes your justification notes for each, and present it along with your other materials. – ACG Oct 04 '19 at 13:17
  • For 2) the original comment from @hyde comes into play. Tool-specific mechanisms for suppressing individual warnings (even code comments) will not necessarily convey enough/any information to a different tool and its human users. You can address this to some extent with the technique I sketched for 1), but fixing the warning itself is also going to be worthwhile. E.g., if a warning is reported with a path that you have reasoned to be impossible, you can put an explicit guard in the code to enforce the impossibility and make sure analysis tools (and your human teammates!) see it too. – ACG Oct 04 '19 at 13:29