Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Silencing the checker
#2
It is not fine to run the code through the static checker, then alter the code. If you change some compiler switches, you must run the code through the tool again or it isn't MISRA-compliant, since MISRA enforces a check by a static analyzer.

However, have in mind that static analyzers tend to be incredibly picky. To filter out incorrect warnings in the tool can be complicated, or perhaps not even possible. So the reason behind compiler switches like this could be a poor static analyzer, and not necessarily just a lazy programmer (although the latter is far more common). I'd take a closer look at each row surrounded by such a compiler switch.

At any rate, it does not break rule 2.4 since that one only concerns code within comments, not within compiler switches.

I would agree that a rule banning compiler switches entirely would be in place - compiler switches (and everything else in the pre-processor) are notorious bug creators.I have banned them in the coding policy for the company I work for, as an extension to MISRA-C.

Why do you want to ban comments for? They are as much a part of the program as the source itself. If your debug and/or production code does not contain any comments, you are either writing very plain, uncomplicated programs, or you are doing something wrong.
<t></t>
Reply


Messages In This Thread

Forum Jump:


Users browsing this thread: 2 Guest(s)