MISRA Discussion Forums

Full Version: Pointer conversions (implicit, explicit, void)
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I would like to ask for some help interpreting MISRA-C:2004. I have a few very simple examples. Please confirm whether my observations below are correct.

1)
#include
void main(void) {
char* string = "Hello World!";
int* result = string;
printf("Result: %d\n", *result);
}

This code is not MISRA-C:2004 compliant, because the implicit pointer conversion is not legal ANSI C. Thus, it violates rule 1.1. Is this observation correct?

2)
#include
void main(void) {
char* string = "Hello World!";
int* result = (int*)string;
printf("Result: %d\n", *result);
}

This code is MISRA-C:2004 compliant. However, the explicit type cast to int* is a violation of advisory rule 11.4. Is this observation correct?

3)
#include
void main(void) {
char* string = "Hello World!";
void* void_ptr = string;
int* result = void_ptr;
printf("Result: %d\n", *result);
}

This code is MISRA-C:2004 compliant. It also does not violate advisory rule 11.4. Is this observation correct?

4)
#include
void main(void) {
char* string = "Hello World!";
void* void_ptr = (void*)string;
int* result = void_ptr;
printf("Result: %d\n", *result);
}

This code is MISRA-C:2004 compliant. However, it now does violate advisory rule 11.4 due to the use of the type cast operator. Is this observation correct?

I do not see how 3) is better than alternative 2) or 4) above. Double casting through void pointers does not seem to be safe practice. It hides the conversion intent, so it makes the code harder to read.

I understand that the main reason for allowing conversions to void pointers is due to legacy reasons (i.e. writing data to memory). Seeing that 11.4 is advisory, would it not be better to refer to "conversions" between different pointers to object, rather than "casting"?
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.