Unclear why this code is not compliant with rule 11.3

Unclear why this code is not compliant with rule 11.3 - Printable Version

+- MISRA Discussion Forums (https://forum.misra.org.uk)
+-- Forum: MISRA C (https://forum.misra.org.uk/forumdisplay.php?fid=4)
+--- Forum: MISRA C:2012 and MISRA C:2023 guidelines (https://forum.misra.org.uk/forumdisplay.php?fid=21)
+---- Forum: 8.11 Pointer type conversions (https://forum.misra.org.uk/forumdisplay.php?fid=166)
+---- Thread: Unclear why this code is not compliant with rule 11.3 (/showthread.php?tid=1197)

Unclear why this code is not compliant with rule 11.3 - m4l490n - 04-08-2015

Hi everybody

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.

Re: Unclear why this code is not compliant with rule 11.3 - fpeelo - 07-08-2015

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/library/aa260976%28v=vs.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?

Re: Unclear why this code is not compliant with rule 11.3 - misra-c - 14-08-2015

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.