CODEWITHSUNDEEP
cmisra
Ankit Shah
Ankit Shah

Reputation: 107

MISRA 11.3: cast from int to pointer

I have one question on how to solve MISRA 2004 11.3 violation.

The code is as follows:

tm_uint8 read( tm_uint8* data)
{
data[0] = *((tm_uint8*)0x00003DD2); 
data[1] = *((tm_uint8*)0x00003DD3);
data[2] = *((tm_uint8*)0x00003DD4);
}

I want to write the value stored at the physical address. It compiles but I have a MISRA violation for 11.3. I want to solve it. Can anyone help me with that?

Upvotes: 2

Views: 3121

Answers (2)

Andrew
Andrew

Reputation: 2312

Note: MISRA-C:2004 Rule 11.3 is equivalent to MISRA C:2012 Rule 11.4

It is accepted that some MISRA C/C++ Rules may cause a violation to be raised, in situations where the method used is necessary.

Because of this, MISRA C provides a mechanism for Deviating a Rule - and this would be the appropriate route for you to follow... please do not try and find a way around the Rule using "clever" code!

As highlighted by this question, accessing specific memory (and/or I/O devices) is one particular case. In fact, one of the examples included in MISRA C:2012 shows this exact use case as being non-compliant with the Rule.

In 2016, the MISRA C Working Group published additional guidance on Compliance, including enhancing the Deviation process... this gives help on what is a justifiable Deviation - and accessing hardware is one of those!

In due course, it is planned to provide more "layered" guidance... but that will not be immediate.

[Please note profile for disclaimer]

Upvotes: 1

Lundin
Lundin

Reputation: 213721

The rationale behind this rule is that MISRA worries about misaligned access when casting from an integer to a pointer. In your case, I assume tm_uint8_t is 1 byte, so alignment shouldn't be an issue here. In that case, the warning is simply a false positive and you can ignore it. This is an advisory rule, so you don't need to raise a deviation.

There is no other work-around, except never working with absolute addresses. Which is most likely not an option here. As you can tell, this rule is very cumbersome when writing hardware-related code, there is just no way such code can follow the rule.

Upvotes: 2

Related Questions