06-06-2012, 10:12 AM
This reply deals only with the questions of compliance raised in your post. Other non-compliances, such as using are outside the scope of this response.
Code that violates a rule may or may not be 'compliant'. As described in Section 4.4, to be compliant, code that violates a rule must be documented and authorised by means of a company-specific procedure. It is therefore easier to talk in terms of whether code violates a given rule rather then whether or not it complies with MISRA C.
This area has received additional treatment in the current draft of the MISRA C:2012 Guidelines.
Code that violates a rule may or may not be 'compliant'. As described in Section 4.4, to be compliant, code that violates a rule must be documented and authorised by means of a company-specific procedure. It is therefore easier to talk in terms of whether code violates a given rule rather then whether or not it complies with MISRA C.
- Yes, this code violates Rule 1.1 because the unqualified type pointed to by the right operand of the assignment must be compatible with the unqualified type pointed to by the left operand. Since char is not compatible with int, this is not valid ISO C.
- The code violates advisory Rule 11.4.
- The code does not violate advisory Rule 11.4.
- The code does not violate advisory Rule 11.4 because the cast is from a pointer to object type (char *) to a pointer to incomplete type (void *).
- the value stored in that pointer to char, and
- details of your implementation such as the alignment requirements of your processor and memory sub-system, what features of the processor and/or operating system are enabled (e.g. emulation of misaligned accesses) and so on.
This area has received additional treatment in the current draft of the MISRA C:2012 Guidelines.
Posted by and on behalf of the MISRA C Working Group