I encountered a warning related to MISRA 2012 Rule 11.4, which flags casting from a pointer to an integer. I attempted to use intptr_t, but it did not resolve the issue. Could anyone provide guidance on how to use it safely? A sample code demonstration would be helpful in resolving the MISRA warning.

Below is the sample code that I implemented, which is triggering the MISRA 2012 Rule 11.4 warning related to casting a pointer to an integer:

float buffer[SIZE];
int32_t casted_ptr;  
casted_ptr=(int32_t)&buffer[0];

I encountered a warning related to MISRA 2012 Rule 11.4, which flags casting from a pointer to an integer. I attempted to use intptr_t, but it did not resolve the issue. Could anyone provide guidance on how to use it safely? A sample code demonstration would be helpful in resolving the MISRA warning.

Below is the sample code that I implemented, which is triggering the MISRA 2012 Rule 11.4 warning related to casting a pointer to an integer:

float buffer[SIZE];
int32_t casted_ptr;  
casted_ptr=(int32_t)&buffer[0];

• c
• misra

• 2 MISRA is extremely strict, often for good reasons, but sometimes it will lead to code that becomes cumbersome and harder to maintain. Sometimes a well-placed cast will be better and is guaranteed to work. But use-case and situation is key, it shouldn't be done in any random code, there must be an actual need to do it, to keep the code clean and good. – Some programmer dude Commented Mar 12 at 8:02
• 2 What does "its not working" mean? Does the code not work any longer or do you just still get MISRA issues reported? As intptr_t is still a integer type, it will not change anything. Also, MISRA 2012 Rule 11.4 explicitely mentions that these types are also not permitted by that rule. – Gerhardh Commented Mar 12 at 8:06
• 3 @Mrk234 all the relevant information should be in the question, not in comments. You can edit it to add the relevant info. – wohlstad Commented Mar 12 at 8:16
• 5 If your question is how to cast a pointer to integer while avoiding the MISRA warning about casting a pointer to integer, that one seems doomed. But that is not your actual problem, is it? So take a step back, look at why the code is trying to do that and maybe there is a way to do that thing safely. – teapot418 Commented Mar 12 at 10:16
• 2 Without showing why you're casting from a pointer to an integer, it's impossible for anyone here to say whether what you're doing is safe or useful. – Thomas Jager Commented Mar 12 at 10:27

1 Answer 1

Rule 11.4 is advisory and it's one of those rules that are "very advisory", as you won't be able to follow it in practice when doing any form of hardware-related programming. The rule simply does not allow any such casts, period.

The rationale given with the rule covers alignment and integer presentation. Other potential problems not mentioned are incorrect addresses and strict aliasing violations.

So basically, it is OK to break this advisory rule if you have concluded that:

• The cast does not lead to misalignment
• The cast does not lead to a value which cannot fit/cannot be represented
• The address leads to valid memory, for example to where a hardware peripheral register resides
• A pointer type does not get de-referenced while it points to something which has a different type than the de-referenced pointer