Electronics > Microcontrollers

MISRA C & OpenSource

<< < (6/8) > >>

newbrain:
So, just for kicks, I compiled cppcheck and tested OP's code.

I get a violation for 8.4 (note that I don't have a file with the rules' text):  maybe we have different versions, I simply compiled the latest master branch.

If the function is declared as static in the prototype, the check gives a clean result - though the actual violated rule should have been 8.7:

--- Quote --- Functions and objects should not be defined with external linkage if they are referenced in only one translation unit
--- End quote ---

"cppcheck --addon misra main.c" of course reports the out of bound access to p[].

While we use cppcheck (and other tools) at work, we do not use the MISRA addon, so I cannot say how reliable it is.

SiliconWizard:

--- Quote from: newbrain on October 14, 2021, 05:28:41 pm ---
--- Quote from: nctnico on October 14, 2021, 05:18:43 pm ---But the OP is putting code through a syntax checking tool with a specific rule set so all bets are off... If someone uses case(1) in code I start to doubt that person's coding skills.

--- End quote ---
I also would not write that way (when using a simple literal) but it's not wrong.
Still, none of the diagnostics was referring to the switch statement - one was for main and one for the other function.  :-//

--- End quote ---

I do not get the diagnostic here either. Can't see what's wrong. But I suspect the problem is with the misra check semir-t is using here. As I said, MISRA-C support is not complete at this point in Cppcheck. And, I don't know what version they are using either...

Digging a bit deeper, it looks like MISRA-C support is not just incomplete in Cppcheck, but it doesn't give you exact messages either, apparently for licensing reasons if I got it right, but I dunno.
Not sure where semir-t got the rules file 'MISRA_C_2012.txt' from. It doesn't seem to be directly provided by Cppcheck. It does have a MISRA-C addon though, but won't give you detailed messages without this file.

Anyway... Running the latest Cppcheck this way on this piece of code:

--- Code: ---cppcheck --addon=misra misrac1.c
--- End code ---
Gives the following - which is not the same...

--- Code: ---misrac1.c:14:4: error: Array 'p[10]' accessed at index 100, which is out of bounds. [arrayIndexOutOfBounds]
  p[100] = 5;
   ^
misrac1.c:4:5: style: misra violation (use --rule-texts=<file> to get proper output) [misra-c2012-8.4]
int getValue (int p);
    ^

--- End code ---

Yes, invoking cppcheck directly instead of the python script misra.py - which will be or is already deprecated - will give you other checks apart from MISRA-C rules. And it does spot an out-of-bounds access.
And the only violated MISRA-C rule it finds is different: 8.4. But I still don't understand it here.

Point is: MISRA-C in Cppcheck is probably rather buggy. You may want to contact the author. Unfortunately, they host the project on Sourceforge, which makes collaborating and raising issues a lot less convenient than with, say, github...

SiliconWizard:

--- Quote from: newbrain on October 14, 2021, 06:23:47 pm ---So, just for kicks, I compiled cppcheck and tested OP's code.

I get a violation for 8.4 (note that I don't have a file with the rules' text):  maybe we have different versions, I simply compiled the latest master branch.

If the function is declared as static in the prototype, the check gives a clean result - though the actual violated rule should have been 8.7:

--- Quote --- Functions and objects should not be defined with external linkage if they are referenced in only one translation unit
--- End quote ---

"cppcheck --addon misra main.c" of course reports the out of bound access to p[].

While we use cppcheck (and other tools) at work, we do not use the MISRA addon, so I cannot say how reliable it is.

--- End quote ---

Dang, you did the exact same thing as I did, as I was writing my previous post! :D

newbrain:

--- Quote from: SiliconWizard on October 14, 2021, 06:54:24 pm ---Dang, you did the exact same thing as I did, as I was writing my previous post! :D

--- End quote ---
:-DD great minds waste their time alike!


--- Quote from: SiliconWizard on October 14, 2021, 06:53:13 pm --- it doesn't give you exact messages either, apparently for licensing reasons if I got it right, but I dunno.
Not sure where semir-t got the rules file 'MISRA_C_2012.txt' from. It doesn't seem to be directly provided by Cppcheck. It does have a MISRA-C addon though, but won't give you detailed messages without this file.

--- End quote ---
Yes, the official position of MISRA is that a tool (open source or not) can just use the rule numbers, as the text is copyrighted and needs licensing (the standard is quite cheap, as standards go: 15£) the do not endorse any specific tool, and they suggest to do exactly what cppcheck is doing to be in the clean.

SiliconWizard:

--- Quote from: newbrain on October 14, 2021, 07:13:57 pm ---
--- Quote from: SiliconWizard on October 14, 2021, 06:54:24 pm ---Dang, you did the exact same thing as I did, as I was writing my previous post! :D

--- End quote ---
:-DD great minds waste their time alike!

--- End quote ---

Ahah yeah. But it's not a complete waste of time, as I too use Cppcheck - just not with MISRA-C rules - and routinely recommend it. At least we now know where it stands regarding MISRA-C. And it doesn't look that good so far. Point is, people having to comply with MISRA-C are likely to work in environments that will hardly tolerate false positives, as they often rely on automated systems that won't tolerate any rule violation.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version