Rule 17.4 and Rule 14.7

[Kdasari]

Hi Folks,

We appreciate the MISRA-C compliance.

We are making our application code into the MISRA-C compliance and can you please clarify below questions.

1./Rule 14.7: This rule says that array indexing is only allowed for pointer arithmetic. We understand that if we manipulate the pointer we may end up some cases accessing the non existing memory but suppose even if we access through the index and index is beyond the size of array declaration here also we end accessing the non existing memory , We have the below code and I think it is safe away of using? Can you please let us know the motivation of this rule and how indexing can avoid the error? Also let us know that the below code is acceptable or not?

void awe_vecAbs(
const float * src,
int srcInc,
float * dst,
int dstInc,
int blockSize)
{
int i;

for (i = 0; i < blockSize; i++)
{
*dst = fabsf (*src);
src = src + srcInc;
dst = dst + dstInc;
}

)
2./ Rule 14.7 says that the function should have the only one single exit but in some cases it is very difficult to compliance with this especially when we check for the error concealment. Please have a look at below code we still can use if ,else conditions but we end up having more checks like this which will degrade the system performance, Can you please let us know what way we can do this in better and motivation of this Rule?
if (currentObject == NULL)
{
return (E_NOT_OBJECT_POINTER);
}
id = awe_fwGetClassType(currentObject);
if (!IsClassValid(id))
{
return (E_NOT_OBJECT_POINTER);
}
*pObject = currentObject->pNextInstance;
if (*pObject == NULL)
{
return (E_NO_MORE_IOPINS);
}
*pClassID = awe_fwGetClassType(*pObject);
return (0);


Best regards,
Kishore.

[Lundin]

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."

[misra-c]

This is being considered as two separate issues.

Part 1 is assigned tracker id 0000022.
Part 2 is assigned tracker id 0000023.