2
\$\begingroup\$

A bit of background: Our team will be programming firmwares for ARM microprocessors. Programming codes should comply with the MISRA C standard. We have decided to check IAR's EWARM package: https://www.iar.com/iar-embedded-workbench/#!?architecture=ARM&currentTab=editions-and-licensing

Looking at the EWARM package list, we see that there are two possible MISRA C checkers:

  1. The standard MISRA C checker which comes in by default with the EWARM package
  2. The MISRA C checker under the optional static analysis package called CSTAT

My question is, what's the difference between the two checkers? Assuming we only have to follow MISRA C compliance, what will we lose if we opt not to buy the optional CSTAT package?

Thanks in advance for any answers.

\$\endgroup\$
  • \$\begingroup\$ The thing about MISRA is that you are generally not writing to the standard, you are writing to whatever the customers conformance tool thinks the standard is.... Find out what MISRA conformance tool the customer is using and then get a copy and write to that. It is far easier to use whatever the customer is going to use for their verification from the start then it is to 'pass' on some tool from one vendor and then fail verification when the customer runs their tool. \$\endgroup\$ – Dan Mills Sep 28 '17 at 11:34
  • \$\begingroup\$ @DanMills You shouldn't write code to blindly follow some static analyser. Most MISRA-checkers on the market are unfortunately quite broken. If there is nobody in the team who actually knows MISRA-C well, then blindly following the tool is a certain way to disaster. \$\endgroup\$ – Lundin Sep 29 '17 at 12:51
  • \$\begingroup\$ This is a pure programming tool question, and although questions regarding writing firmware are on-topic here, it is usually better to ask such questions at stackoverflow.com. (Though please note that tool/shopping recommendation questions are off-topic on both sites.) \$\endgroup\$ – Lundin Sep 29 '17 at 12:56
  • \$\begingroup\$ @Lundin, you really need to write to both meet a reasonable interpretation of the standard AND satisfy whatever stupid tool the customer is using for their conformance verification. I would absolutely not advocate just writing to pass the verification tool, but you do NEED to pass the customers tools checks as well as conforming to the standard and these are rather more orthogonal then one would hope. \$\endgroup\$ – Dan Mills Sep 29 '17 at 14:38
  • \$\begingroup\$ @DanMills Rather, you should pass your own tool checks. The best way to implement MISRA-C is to creating a company coding standard based on MISRA and then use that one for all projects. MISRA-C per project basis will be burdensome. If you have a coding standard, you can also write down all deviations and rationales there. Meaning that individual programmers won't be allowed to raise deviations, but rather such deviations need to be raised company-wide by updating the document. Once this is in place, it is much easier to argue against various tool warnings. \$\endgroup\$ – Lundin Oct 2 '17 at 8:57
0
\$\begingroup\$

I asked the same question to IAR last winter. "Do I need to buy C-STAT for MISRA-C checks?". Rough translation to English from my correspondence with them:

Yes, MISRA-C checks are done by C-STAT. It is integrated inside the IDE, so you need to buy an EWARM version with a C-STAT license.

To be sure, ask IAR sales. You'll want to ask them about pricing anyway.

However, you need to know which MISRA-C you are using. If you don't, you shouldn't be doing this tool purchase. IAR supports both MISRA-C:2012 and MISRA-C:2004.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.