05-10-2011, 01:32 PM
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
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
<t></t>