We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
MISRA stands for "Motor Industry Software Reliability Association". IAR has an Embedded Workbench which I believe is a Tester to verify the implementation for the MISRA C rules.
Does KEIL have a such a tool?
If there a PDF document available that spells out the rules. I have search and all I can find are test suites.
(for example the "Goto must not be used." rule).
that rule is broken "every day by everybody"
What is a switch statement but a bunch of "if - goto" statements?
HOWEVER, the C 'structure' does not lend itself very well to the implemetation of GOTO, so, thinking of it I have no assembler that is not full of GOTO and no C that has any.
Erik
that rule is broken "every day by everybody"<p>
If you want to write code in compliance with MISRA-C rules, you better not break that rule, or your code will not comply with the standard anymore.
Same thing goes for using a break; statement outside a switch/case structure, using a continue; statement, or using more than one return statement in a function.
"Same thing goes for using a break; statement outside a switch/case structure, using a continue; statement, or using more than one return statement in a function."
Oops! Bad Dan. Bad, bad Dan!
that rule is broken that rule is broken "every day by everybody"<p>
I did not say anything about that an actual GOTO statement was used "every day by everybody", what I said is that a switch statement is the equivalent of (if - goto) and thus if you use a switch statement (which MISRA allows) you are in fact using GOTOs.
"a switch statement is the equivalent of (if - goto)"
equiverlent of goto in 8051 is jmp yes
you be try writing assemblery with no jmp and yeou have only v little code you know
but docomenent is MISRA-C not MISRA-8051 so not good to say equiverelent switch if-goto
whot profffesional C coder do use goto????? i not know you know
i do not you thinking yes
goto really is useful in some situations.
However, all usage should be very similar to the usage of break and continue, but with the ability to make it multi-level, i.e. to break out of (or restart) more than one encapsulation.
You might have a function:
void fnk(void) { restart: do_something(); for (;;) { do_more(); switch (x) { case 1: if (error) goto fail; do_work(); break; case 10: do_even_more(); break; default: goto restart; } } fail: do_cleanup(); }
Yes, it is possible to solve all flow problems with flags, a large set of conditionals, and optional extra loops, but there comes a point where these flags gets very hard to read. The code must check if it should leave (or restart) first level, then second level, ...
"... but there comes a point where these flags gets very hard to read."
And thus become a potential source of errors themselves when the logic they control is not obvious.
And that's the problem I see about the MISRA ruleset. It is not intended to reduce errors, but to eliminate ambiguities and implementation-specific behavior of C - even at the cost of introducing additional sources of errors and degrading performance significantly.