Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Rule 17.4 and Rule 14.7
#2
I believe you accidently posted in the wrong forum, should have been chp 17.

1) is a very good question, I asked the very same one here: http://www.misra.org.uk/forum/viewtopic.php?f=73&t=641
MISRA replied that they agreed that there is no difference between pointer arithmetic and array indexing, but that they still insist on the array syntax.
So I guess this rule should be regarded as a style guide rather than safety-related. Personally I made a deviation from MISRA-C for this rule, since no safety issue exists.

2) is also a very good question! :) I think the reason behind this rule is that the EN 61508 standard ("functional safety", SIL etc) mentions somewhere that a function should only have one return statement. That one is a nonsense standard written by bureaucrats rather than engineers, yet it is enforced by law in some countries / areas of application, so one simply has to cope with it and implement it.

The rule works well for small functions, and in those there should indeed only be one return statement for clarity's sake. But when you have complex functions with a lot of error checking, the rule simply can't be applied, for safety- and realtime reasons. If you find a critical error early on in a function, you should take action as soon as possible. My own solution to this rule was to support it with deviations, in those cases where it makes the code less readable, and in those cases where safety and realtime is highly prioritized.

In case it is of any interest, this is the exception I made for my own MISRA implementation:

"Parser functions or safety-critical functions where the amount of error control is vast. Having just one single return statement in such functions will only obfuscate the code and make it less readable. As a rule of thumb, Rule xxx shall only be used in cases where it makes the code more readable."
<t></t>
Reply


Messages In This Thread

Forum Jump:


Users browsing this thread: 1 Guest(s)