MISRA Discussion Forums

Dear all,

below, you find code that shall be full MISRA-C:2004 compatible except MISRA rule 17.1 (according to my compiler). I removed the header file module.h for readability.

[code]
/* now module.c begins */
float32_t Defaults[6];

void misra17_1test(const float32_t in[6])
{
uint32_t s = 0u;
float32_t mythreshold = 0.0f;
float32_t tmpMax = 0.0f;
for (s = 0u; s < 6u; s++) {
mythreshold = in[s]; /* a MISRA 17.1 violation is detected here by compiler */

/* do something */

if (tmpMax > mythreshold) {
/* do something */
}
else {
/* do something */
}
}
}
*-----------------------------------------------------------------------------------------*/
/* now the main.c module begins */
extern float32_t Defaults[6];

int32_t main(void)
{
int32_t j = 0;
for(j=0; j

Rule 17.1 is "Pointer arithmetic shall only be applied to pointers that address an array or array element".

So it looks like your compiler is treating the parameter in as a pointer, not recognising that it points to an array.

According to K&R 2nd edition, "As formal parameters in a function definition,
char s[];
and
char *s;
are equivalent; we prefer the latter because it says more explicitly that the parameter is a pointer."
So maybe the compiler is reducing "const float32_t in[6]" to "const float32_t *in" before checking for MISRA violations?

Yes, your function prototype says "in[6]" but I don't believe C pays any attention to the "6".

This worries me, because I would like to have code that is as compliant as possible, and I don't see how to declare a function that operates on an array, that would be compliant. I asked here about whether it is possible (even the innocuous strlen() cannot be defined in a compliant way, unless I misunderstand).

Frank

The parameter "in" is pointing to the first element of the array "Defaults" so the array indexing operation does not break Rule 17.1.