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.
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.
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:
cppcheck --addon=misra misrac1.c
Gives the following - which is not the same...
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);
^
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...