<![CDATA[MISRA Discussion Forums - 8.11 Pointer type conversions]]> https://forum.misra.org.uk/ Thu, 05 Nov 2026 13:24:08 +0000 MyBB <![CDATA[11.6 pointer to pointer to void]]> https://forum.misra.org.uk/showthread.php?tid=1765 Tue, 17 Mar 2026 20:43:04 +0000 dunno]]> https://forum.misra.org.uk/showthread.php?tid=1765
Code:
void * ptr;

uint32_t addr = (uint32_t)&ptr;

or does this code violate any of the other rules?]]>
Code:
void * ptr;

uint32_t addr = (uint32_t)&ptr;

or does this code violate any of the other rules?]]> <![CDATA[11.9 and function calls and returned pointers]]> https://forum.misra.org.uk/showthread.php?tid=1738 Mon, 26 May 2025 07:22:04 +0000 danielmarjamaki2]]> https://forum.misra.org.uk/showthread.php?tid=1738
Code:
int* f1(void) {
    return 0;  // 11.9 ?
}

And does this violate 11.9:

Code:
void f2(int* ptr);

void f3(void) {
    f2(0);
}

Do you consider returns and function calls to be "assignments" otherwise it seems to me that the Amplification says these are compliant?

The last example in the PDF does suggest that function calls should be considered to be "assignments" however there is no non-compliant example code that I can rely on.

Thank you]]>
Code:
int* f1(void) {
    return 0;  // 11.9 ?
}

And does this violate 11.9:

Code:
void f2(int* ptr);

void f3(void) {
    f2(0);
}

Do you consider returns and function calls to be "assignments" otherwise it seems to me that the Amplification says these are compliant?

The last example in the PDF does suggest that function calls should be considered to be "assignments" however there is no non-compliant example code that I can rely on.

Thank you]]> <![CDATA[Strict aliasing rule]]> https://forum.misra.org.uk/showthread.php?tid=1628 Mon, 25 Jul 2022 10:17:56 +0000 suruena]]> https://forum.misra.org.uk/showthread.php?tid=1628
Even if the rule is technically correct, in my opinion readers will normally focus on the first paragraph, just analysing the alignment restrictions (and endianness) of the specific platform for justifying specific deviations (like using type punning through pointer conversion for needed format conversions). For example, justifying the conversion of a uint32_t into an array of two uint16_t, or a 32-bit float into a uint32_t. However, the part about undefined behavior is probably not highlighted enough, specially now that current compilers will take advantage of this undefined behavior to generate broken code due to the type aliasing analysis (reordering assignments or even removing code as the compiler is not required to consider the dependencies between those objects due to the undefined behavior, unless aliasing through a char pointer type or due to a few other exceptions).

I think it would be much more useful for the reader to mention the "strict aliasing rule" (as this is the term normally used to warn about these problems in technical forums) and the possibility to get "miscompiled" code at high optimization levels. Also, I think it would be very appreciated to give some guidance of possible standard-compliant solutions like using memcpy instead (moreover as the compiler will probably remove the call overhead if optimizations enabled), copying into an union (which may also be optimized by the compiler, not really generating any data copy) if the compiler is compliant with C99 T3, or even disabling the strict aliasing when compiling (like using -fno-strict-aliasing in GCC), in addition to the already mentioned access through a pointer to a char type.  Even if it cannot be ensured the universal adequacy of these solutions, the readers will be warned about sophisticated compilers and the strict aliasing rule, and will be aware about possible solutions available to be considered in their specific platform. Thank you very much.

Best regards,
Santiago]]>
Even if the rule is technically correct, in my opinion readers will normally focus on the first paragraph, just analysing the alignment restrictions (and endianness) of the specific platform for justifying specific deviations (like using type punning through pointer conversion for needed format conversions). For example, justifying the conversion of a uint32_t into an array of two uint16_t, or a 32-bit float into a uint32_t. However, the part about undefined behavior is probably not highlighted enough, specially now that current compilers will take advantage of this undefined behavior to generate broken code due to the type aliasing analysis (reordering assignments or even removing code as the compiler is not required to consider the dependencies between those objects due to the undefined behavior, unless aliasing through a char pointer type or due to a few other exceptions).

I think it would be much more useful for the reader to mention the "strict aliasing rule" (as this is the term normally used to warn about these problems in technical forums) and the possibility to get "miscompiled" code at high optimization levels. Also, I think it would be very appreciated to give some guidance of possible standard-compliant solutions like using memcpy instead (moreover as the compiler will probably remove the call overhead if optimizations enabled), copying into an union (which may also be optimized by the compiler, not really generating any data copy) if the compiler is compliant with C99 T3, or even disabling the strict aliasing when compiling (like using -fno-strict-aliasing in GCC), in addition to the already mentioned access through a pointer to a char type.  Even if it cannot be ensured the universal adequacy of these solutions, the readers will be warned about sophisticated compilers and the strict aliasing rule, and will be aware about possible solutions available to be considered in their specific platform. Thank you very much.

Best regards,
Santiago]]> <![CDATA[Rule 11.6. A cast between pointer to void and an arithmetic type. Value of the rule.]]> https://forum.misra.org.uk/showthread.php?tid=1453 Thu, 06 Sep 2018 12:18:04 +0000 l.inc]]> https://forum.misra.org.uk/showthread.php?tid=1453 intptr_t/uintptr_t and void *:

  1. Quote:Conversion of an integer into a pointer to void may result in a pointer that is not correctly aligned, resulting in undefined behaviour.
    Would you, please, explain how this rationale is compatible with the following statement in the C90/C99 standards:
    C99. 6.2.5 Types. §27 Wrote:A pointer to void shall have the same representation and alignment requirements as a pointer to a character type.
    As character pointers contain addresses of individual bytes, they cannot be unaligned. Hence pointers to void cannot be unaligned too, right?
    Moreover, for the cases, in which the alignment problem indeed may occur, the restriction you define (rule 11.4) is, in contrast to 11.6, only advisory.
  2. Quote:Conversion of a pointer to void into an integer may produce a value that cannot be represented in the chosen integer type resulting in undefined behaviour.
    This rationale does not apply to intptr_t/uintptr_t.
  3. Quote:Conversion between any non-integer arithmetic type and pointer to void is undefined.
    This rationale looks like it would deserve a separate rule, as the limitations of these conversions for integers and non-integer arithmetic types are very different.

In addition to failing to find an appropriate rationale for disallowing conversions between intptr_t/uintptr_t and void * I see positive value in favoring these over conversions between intptr_t/uintptr_t and object pointers. One advantage is the above mentioned alignment, but also that holding addresses as pointers to void prevents accidental accesses to the object. The more specific case of mine is when pointers to objects are produced by de-serialization (for which uintptr_t is the most preferred type) and the objects are used nearly nowhere in the program but in copy operations via memcpy. Improving compliance with MISRA C:2012 requires to convert the value into an object pointer first, which creates the risk of accidental dereferencing in the code, and only then into a pointer to void to pass the value to memcpy. This allows to trade a deviation from the required rule 11.6 for the deviation of the advisory rule 11.4. But at the same time the code then seems to become less safe.

So were the conversions between intptr_t/uintptr_t and void * disallowed unintentionally or do I just miss a safer way to handle the above described situations than to deviate from 11.6?]]> intptr_t/uintptr_t and void *:

  1. Quote:Conversion of an integer into a pointer to void may result in a pointer that is not correctly aligned, resulting in undefined behaviour.
    Would you, please, explain how this rationale is compatible with the following statement in the C90/C99 standards:
    C99. 6.2.5 Types. §27 Wrote:A pointer to void shall have the same representation and alignment requirements as a pointer to a character type.
    As character pointers contain addresses of individual bytes, they cannot be unaligned. Hence pointers to void cannot be unaligned too, right?
    Moreover, for the cases, in which the alignment problem indeed may occur, the restriction you define (rule 11.4) is, in contrast to 11.6, only advisory.
  2. Quote:Conversion of a pointer to void into an integer may produce a value that cannot be represented in the chosen integer type resulting in undefined behaviour.
    This rationale does not apply to intptr_t/uintptr_t.
  3. Quote:Conversion between any non-integer arithmetic type and pointer to void is undefined.
    This rationale looks like it would deserve a separate rule, as the limitations of these conversions for integers and non-integer arithmetic types are very different.

In addition to failing to find an appropriate rationale for disallowing conversions between intptr_t/uintptr_t and void * I see positive value in favoring these over conversions between intptr_t/uintptr_t and object pointers. One advantage is the above mentioned alignment, but also that holding addresses as pointers to void prevents accidental accesses to the object. The more specific case of mine is when pointers to objects are produced by de-serialization (for which uintptr_t is the most preferred type) and the objects are used nearly nowhere in the program but in copy operations via memcpy. Improving compliance with MISRA C:2012 requires to convert the value into an object pointer first, which creates the risk of accidental dereferencing in the code, and only then into a pointer to void to pass the value to memcpy. This allows to trade a deviation from the required rule 11.6 for the deviation of the advisory rule 11.4. But at the same time the code then seems to become less safe.

So were the conversions between intptr_t/uintptr_t and void * disallowed unintentionally or do I just miss a safer way to handle the above described situations than to deviate from 11.6?]]> <![CDATA[Rule 11.9: Does this struct initialization violate rule 11.9?]]> https://forum.misra.org.uk/showthread.php?tid=1371 Wed, 27 Sep 2017 10:09:47 +0000 fst-mra]]> https://forum.misra.org.uk/showthread.php?tid=1371
our analysis tool reports the following struct initialization to violate rule 11.9 (macro NULL is the only permitted form of integer null pointer constant):

static const myType myStruct = {
64,
{0xa0,0xa0,0xa0,0xa0,0xa0,0xa0,0xa0,0xa0,0xa0,0xa0,0xa0,0xa0,0xa0,0xa0,0xa0,0xa0},
0
};

with:
typedef unsigned short uint16;
typedef unsigned char uint8;
typedef struct {
uint16 myVariable01;
uint8 myArray [16];
uint8 myVariable02;
} myType;

Unfortunately, neither from the tool documentation nor from the MISRA documentation we can conclude why this initialization would be non-compliant. Also we cannot see what the risk behind this deviation would be. Is this deviation false-positive? Does it introduce any portability, maintainability etc. risk?

Thanks for your support.
Frank]]>
our analysis tool reports the following struct initialization to violate rule 11.9 (macro NULL is the only permitted form of integer null pointer constant):

static const myType myStruct = {
64,
{0xa0,0xa0,0xa0,0xa0,0xa0,0xa0,0xa0,0xa0,0xa0,0xa0,0xa0,0xa0,0xa0,0xa0,0xa0,0xa0},
0
};

with:
typedef unsigned short uint16;
typedef unsigned char uint8;
typedef struct {
uint16 myVariable01;
uint8 myArray [16];
uint8 myVariable02;
} myType;

Unfortunately, neither from the tool documentation nor from the MISRA documentation we can conclude why this initialization would be non-compliant. Also we cannot see what the risk behind this deviation would be. Is this deviation false-positive? Does it introduce any portability, maintainability etc. risk?

Thanks for your support.
Frank]]> <![CDATA[Rule 11.9: Does array initialization to 0 violate Rule 11.9?]]> https://forum.misra.org.uk/showthread.php?tid=1370 Wed, 27 Sep 2017 10:00:38 +0000 fst-mra]]> https://forum.misra.org.uk/showthread.php?tid=1370
our analysis tool reports the following array initialization to violate rule 11.9 (macro NULL is the only permitted form of integer null pointer constant):

uint8 myBuffer[8] = {0u}; // with "typedef unsigned char uint8;"

Unfortunately, neither from the tool documentation nor from the MISRA documentation we can conclude why this "standard" construct would be non-compliant. Also we cannot see what the risk behind this deviation would be. Is this deviation false-positive? Does it introduce any portability, maintainability etc. risk?

Thanks for your support.
Frank]]>
our analysis tool reports the following array initialization to violate rule 11.9 (macro NULL is the only permitted form of integer null pointer constant):

uint8 myBuffer[8] = {0u}; // with "typedef unsigned char uint8;"

Unfortunately, neither from the tool documentation nor from the MISRA documentation we can conclude why this "standard" construct would be non-compliant. Also we cannot see what the risk behind this deviation would be. Is this deviation false-positive? Does it introduce any portability, maintainability etc. risk?

Thanks for your support.
Frank]]> <![CDATA[Rule 11.3 pointer to array of const element]]> https://forum.misra.org.uk/showthread.php?tid=1333 Thu, 06 Apr 2017 13:55:26 +0000 grunwald]]> https://forum.misra.org.uk/showthread.php?tid=1333
Code:
static void use_array(uint8_t const (* const arr)[4])
{
}

int main()
{
    uint8_t aAction[4] = {0, 0, 0, 0};
    use_array((uint8_t const(*)[4]) &aAction); // 11.3 violation?
}

As I read rule 11.3, the cast in the use_array call violates rule 11.3: the target type of the pointer is "4-element array of const uint8_t". Given that the "const" is not at top-level, adding it is not permitted by this rule.

However, that raises the question: how can I call use_array() from Misra-compliant code?

Note that the cast is required by ISO C (gcc says: pointers to arrays with different qualifiers are incompatible in ISO C [-Wpedantic]).
However, in C++, an implicit conversion exists for this case.]]>
Code:
static void use_array(uint8_t const (* const arr)[4])
{
}

int main()
{
    uint8_t aAction[4] = {0, 0, 0, 0};
    use_array((uint8_t const(*)[4]) &aAction); // 11.3 violation?
}

As I read rule 11.3, the cast in the use_array call violates rule 11.3: the target type of the pointer is "4-element array of const uint8_t". Given that the "const" is not at top-level, adding it is not permitted by this rule.

However, that raises the question: how can I call use_array() from Misra-compliant code?

Note that the cast is required by ISO C (gcc says: pointers to arrays with different qualifiers are incompatible in ISO C [-Wpedantic]).
However, in C++, an implicit conversion exists for this case.]]> <![CDATA["null pointer constant"?]]> https://forum.misra.org.uk/showthread.php?tid=1324 Wed, 08 Mar 2017 23:06:02 +0000 swestin]]> https://forum.misra.org.uk/showthread.php?tid=1324
the value 0, optionally cast to void *

Does this allow floating-point zero as a null pointer constant, e. g.

int32_t * pint = (void*)0.0f;

That seems crazy to me, but Rule 11.4 specifically allows a "null pointer constant that has integer type", whereas other mentions (Rules 11.1 and 11.2) omit "integer".

Was the intent to specify an integer zero?]]>
the value 0, optionally cast to void *

Does this allow floating-point zero as a null pointer constant, e. g.

int32_t * pint = (void*)0.0f;

That seems crazy to me, but Rule 11.4 specifically allows a "null pointer constant that has integer type", whereas other mentions (Rules 11.1 and 11.2) omit "integer".

Was the intent to specify an integer zero?]]> <![CDATA[Rule 11.8: non-compatible pointees]]> https://forum.misra.org.uk/showthread.php?tid=1304 Thu, 05 Jan 2017 16:58:31 +0000 pmhill]]> https://forum.misra.org.uk/showthread.php?tid=1304
[code]
const int a[10];
int *pi;
int **ppi;
const int **cppi;
const float **cppf;

void f() {
pi = (int*) &a; /* int * ]]>
[code]
const int a[10];
int *pi;
int **ppi;
const int **cppi;
const float **cppf;

void f() {
pi = (int*) &a; /* int * ]]> <![CDATA[Does Rule 11.9 allow indirect expansion from NULL?]]> https://forum.misra.org.uk/showthread.php?tid=1272 Wed, 14 Sep 2016 14:23:14 +0000 rgamble]]> https://forum.misra.org.uk/showthread.php?tid=1272
Code:
#define FOO NULL
int32_t *p1 = FOO;
]]>
Code:
#define FOO NULL
int32_t *p1 = FOO;
]]> <![CDATA[11.3 - char * to uint8_t *]]> https://forum.misra.org.uk/showthread.php?tid=1238 Wed, 27 Apr 2016 11:05:01 +0000 delta_controls]]> https://forum.misra.org.uk/showthread.php?tid=1238
Code:
extern void print(const uint8_t *text);

int main(void)
{
    print("Some text");
}

Am I correct in thinking that this is compliant? Or does the exception to rule 11.3 only apply when conversions are explicit?

Thanks.]]>
Code:
extern void print(const uint8_t *text);

int main(void)
{
    print("Some text");
}

Am I correct in thinking that this is compliant? Or does the exception to rule 11.3 only apply when conversions are explicit?

Thanks.]]> <![CDATA[Unclear why this code is not compliant with rule 11.3]]> https://forum.misra.org.uk/showthread.php?tid=1197 Tue, 04 Aug 2015 21:00:00 +0000 m4l490n]]> https://forum.misra.org.uk/showthread.php?tid=1197
I'm having a very hard time understanding why the following code gives me two errors regarding rule 11.3.

Code:
#define NUM_TASKS 3

typedef struct
{
  uint32_t *CpuUtilizationPercent;
  uint32_t *Counter;
  TaskParam_t *Params;
  TaskConfig_t *Tasks;
  uint8_t NumTasks;
} PPTS_Config_t;

static uint32_t PPTS_CpuUtilizationPercent;
static uint32_t PPTS_Counter;

static TaskParam_t TaskParams[NUM_TASKS];

static TaskConfig_t TaskConfig[NUM_TASKS];

const PPTS_Config_t CnfPPTS =
{
  &PPTS_CpuUtilizationPercent,
  &PPTS_Counter,
  TaskParams,  /* MISRA-C rule 11.3 violation */
  TaskConfig,   /* MISRA-C rule 11.3 violation */
  NUM_TASKS
};
And in both cases the error is: A cast shall not be performed between a pointer to object type and a pointer to a different object type

The thing here is that both TaskParams and TaskConfig are pointers of the same type that are the struct elements Params and Tasks. I don't understand how ---TaskConfig_t TaskConfig[NUM_TASKS]--- is different from ---TaskConfig_t *Tasks---. They seem similar to me, or, am I messign something?

Thank you very much for helping and I hope this could be explained because I'm really frustrated.

Regards.]]>
I'm having a very hard time understanding why the following code gives me two errors regarding rule 11.3.

Code:
#define NUM_TASKS 3

typedef struct
{
  uint32_t *CpuUtilizationPercent;
  uint32_t *Counter;
  TaskParam_t *Params;
  TaskConfig_t *Tasks;
  uint8_t NumTasks;
} PPTS_Config_t;

static uint32_t PPTS_CpuUtilizationPercent;
static uint32_t PPTS_Counter;

static TaskParam_t TaskParams[NUM_TASKS];

static TaskConfig_t TaskConfig[NUM_TASKS];

const PPTS_Config_t CnfPPTS =
{
  &PPTS_CpuUtilizationPercent,
  &PPTS_Counter,
  TaskParams,  /* MISRA-C rule 11.3 violation */
  TaskConfig,   /* MISRA-C rule 11.3 violation */
  NUM_TASKS
};
And in both cases the error is: A cast shall not be performed between a pointer to object type and a pointer to a different object type

The thing here is that both TaskParams and TaskConfig are pointers of the same type that are the struct elements Params and Tasks. I don't understand how ---TaskConfig_t TaskConfig[NUM_TASKS]--- is different from ---TaskConfig_t *Tasks---. They seem similar to me, or, am I messign something?

Thank you very much for helping and I hope this could be explained because I'm really frustrated.

Regards.]]> <![CDATA[Does constness count as a type difference in rule 11.2?]]> https://forum.misra.org.uk/showthread.php?tid=1196 Thu, 23 Jul 2015 15:55:09 +0000 fpeelo]]> https://forum.misra.org.uk/showthread.php?tid=1196
typedef struct s_EthBuf *TEthBuf;
typedef struct s_EthBuf const *CTEthBuf;

The actual type, and an instance of the type, are declared in the translation unit that also defines the functions which operate on it.

Some functions need to modify the contents of the object, so they take a parameter of type TEthBuf. Some do not; they take a parameter of type CTEthBuf.

PC-Lint tells me that assigning a TEthBuf pointer to a variable of type CTEthBuf, or const TEthBuf, or passing it to a function which takes CTEthBuf as its parameter type, violates rule 11.2.

So: if I have struct s_EthBuf X then the following get the warning the 11.2 is violated:
CTEthBuf a = X;
const TEthBuf b = X;
foo(x)
- where foo is declared as void foo(CTEthBuf buf);

But it's OK to do
TEthBuf c = X;

But the type is the same, it's just that foo() doesn't change anything in the object.

Is PC-Lint correct here, when it believes that the types are different from the point of view of rule 11.2?]]>
typedef struct s_EthBuf *TEthBuf;
typedef struct s_EthBuf const *CTEthBuf;

The actual type, and an instance of the type, are declared in the translation unit that also defines the functions which operate on it.

Some functions need to modify the contents of the object, so they take a parameter of type TEthBuf. Some do not; they take a parameter of type CTEthBuf.

PC-Lint tells me that assigning a TEthBuf pointer to a variable of type CTEthBuf, or const TEthBuf, or passing it to a function which takes CTEthBuf as its parameter type, violates rule 11.2.

So: if I have struct s_EthBuf X then the following get the warning the 11.2 is violated:
CTEthBuf a = X;
const TEthBuf b = X;
foo(x)
- where foo is declared as void foo(CTEthBuf buf);

But it's OK to do
TEthBuf c = X;

But the type is the same, it's just that foo() doesn't change anything in the object.

Is PC-Lint correct here, when it believes that the types are different from the point of view of rule 11.2?]]> <![CDATA[Rule 11.1, 11.2 (and others?) vs conversion caused by equality operators (and similar)?]]> https://forum.misra.org.uk/showthread.php?tid=1184 Wed, 03 Jun 2015 14:14:05 +0000 pkruk]]> https://forum.misra.org.uk/showthread.php?tid=1184
rules 11.1 and 11.2 disallow conversions between pointer to a function or incomplete type, and any other type:

Code:
void (*fp1)(short);
void (*fp2)(int);

fp2 = fp1;          /* Not-compliant - different function */
fp2 = 0x8000;       /* Not-compliant - integer */

What if the conversion happens for example in equality operator:
Code:
fp2 == fp1;         /* Compliant or Not-compliant ? */
fp2 != 0x8000;      /* Compliant or Not-compliant ? */

Following example from Rule 11.1 suggests it's also non-compliant:
Code:
if ( fp2 != NULL )  /* Compliant - exception 1 (NULL) */
]]>
rules 11.1 and 11.2 disallow conversions between pointer to a function or incomplete type, and any other type:

Code:
void (*fp1)(short);
void (*fp2)(int);

fp2 = fp1;          /* Not-compliant - different function */
fp2 = 0x8000;       /* Not-compliant - integer */

What if the conversion happens for example in equality operator:
Code:
fp2 == fp1;         /* Compliant or Not-compliant ? */
fp2 != 0x8000;      /* Compliant or Not-compliant ? */

Following example from Rule 11.1 suggests it's also non-compliant:
Code:
if ( fp2 != NULL )  /* Compliant - exception 1 (NULL) */
]]> <![CDATA[Example at 11.1 and 11.2]]> https://forum.misra.org.uk/showthread.php?tid=1177 Wed, 29 Apr 2015 09:24:31 +0000 ogawa.kiyoshi]]> https://forum.misra.org.uk/showthread.php?tid=1177
#include /* to obtain macro NULL */

in example codes in 11.9

#include

A freestanding environment needs stdarg.h not sodlib.h.
So I prefer to obtain macro NULL,
#include // to obtain macro NULL

Is it reasonable?

ps. in 11.9
/* Could also be stdio.h, stdlib.h and others */

I prefer
/* A free standing environment needs stddef.h */
/* Could also be stdio.h, stdlib.h and others in host environments */

Best Regards.]]>
#include /* to obtain macro NULL */

in example codes in 11.9

#include

A freestanding environment needs stdarg.h not sodlib.h.
So I prefer to obtain macro NULL,
#include // to obtain macro NULL

Is it reasonable?

ps. in 11.9
/* Could also be stdio.h, stdlib.h and others */

I prefer
/* A free standing environment needs stddef.h */
/* Could also be stdio.h, stdlib.h and others in host environments */

Best Regards.]]>