Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Pointer conversions (implicit, explicit, void)
#2
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.

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

  2. The code violates advisory Rule 11.4.

  3. The code does not violate advisory Rule 11.4.

  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 *).
All of (2), (3) and (4) convert a "pointer to char" into a "pointer to int". Whether this will do what you want or expect will depend on:

  1. the value stored in that pointer to char, and
  2. 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.
Your observation that the nature of the conversion, explicit vs implicit, has no effect on the outcome is correct. It is just as 'bad' to perform the conversion indirectly by means of void * as it is to violate Rule 11.4 and perform it directly.

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
Reply


Messages In This Thread

Forum Jump:


Users browsing this thread: 2 Guest(s)