Unclear why this code is not compliant with rule 11.3

Moderators: misra-c, david ward

Post Reply
m4l490n
Posts: 2
Joined: Thu Jul 30, 2015 6:26 pm
Company: Magna International

Unclear why this code is not compliant with rule 11.3

Post by m4l490n » Tue Aug 04, 2015 10:00 pm

Hi everybody

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

Code: Select all

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

fpeelo
Posts: 15
Joined: Fri Jul 20, 2007 3:31 pm

Re: Unclear why this code is not compliant with rule 11.3

Post by fpeelo » Fri Aug 07, 2015 11:48 am

Hi

I'm not part of MISRA, I'm just hanging around waiting for an answer to my own questions, so don't take this as gospel, but...

your code example does not show how TaskParam_t and TaskConfig_t are defined, maybe they are different typedefs?

If one intended that two variables were the same type, presumably one would use the same typedef for both. Using a different typedef suggests that the implementation of one could change without changing the implementation of the other; so, they might currently be declared identically but they are different types.

This is a similar idea to the original Hungarian notation (not "systems Hungarian"!) where "the concept of "type" in this context is determined by the set of operations that can be applied to a quantity" ... "The point is that "integers" x and y are not of the same type if Position (x,y) is legal but Position (y,x) is nonsensical". (https://msdn.microsoft.com/en-us/librar ... 60%29.aspx)

He's saying that even if x and y are both, say, uint16_t, they cannot be considered the same type if they cannot be used for the same thing.

Now, it would be a very clever static analyser that would detect such semantic use of a simple integer type; that's not going to happen. But if you use typedef, you are giving the analyser a very clear hint. If you have separate typedefs for TaskParam_t and TaskConfig_t, you must have wanted to use them for different purposes, so to define different types, even if today the implementations of the two types look similar.

Does that help?

misra-c
Posts: 571
Joined: Thu Jan 05, 2006 1:11 pm

Re: Unclear why this code is not compliant with rule 11.3

Post by misra-c » Fri Aug 14, 2015 11:47 am

Rule 11.3 applies after the implicit conversion of "array of type" to "pointer to type", which is described in C99 section 6.3.2.1paragraph 3.

Therefore both lines are compliant with rule 11.3.
---
Posted by and on behalf of
the MISRA C Working Group

Post Reply

Return to “8.11 Pointer type conversions”