Misra Rule 18.2. An object shall not be assigned to an overlapping object

[hammer1234]

Hello

I would like to create a test case that violates the following MISRA
C:2004 rule .

Misra Rule 18.2. An object shall not be assigned to an overlapping
object.
"The behaviour is undefined when two objects are created which have
some overlap in memory and one is copied to the other"

The sample I have created is
---------------------------------------------------------------
#include <string.h>

typedef char char_t;

char_t main(void)
{

char_t Buffer[]= "is this a violation?";
memcpy(&Buffer[5], &Buffer[10], 10); /*Violation, memory over lapped,
result will equal "is thviolation?tion?"*/

return(Buffer[5]);
}

-------------------------------------------------------------------------------------
However the rule relates to copying one object to another different
object where the two objects have some memory overlapping. It could
possibly be related to using unions.

Can anyone think of a way I can violate this rule??

 

[Richard Bos]

I would like to create a test case that violates the following MISRA
C:2004 rule .

Misra Rule 18.2. An object shall not be assigned to an overlapping
object.
"The behaviour is undefined when two objects are created which have
some overlap in memory and one is copied to the other"

The sample I have created is
---------------------------------------------------------------
#include <string.h>

typedef char char_t;

char_t main(void)
{

char_t Buffer[]= "is this a violation?";
memcpy(&Buffer[5], &Buffer[10], 10); /*Violation, memory over lapped,
result will equal "is thviolation?tion?"*/

No. _May_ equal that. The result is, as Misra states correctly,
undefined. Anything may happen; getting the result you expect is a valid
result, not copying anything is a valid result, copying something else
is a valid result, crashing the program is equally valid. If you don't
want that, use memmove(), not memcpy().

However the rule relates to copying one object to another different
object where the two objects have some memory overlapping. It could
possibly be related to using unions.

Possibly. If you want to know what Misra had in mind when they wrote
that rule, ask Misra.

Can anyone think of a way I can violate this rule??

*Shrug* Copy one union member to another?

Richard

 

[hammer1234]

*Shrug* Copy one union member to another?

Yeah that is the only way I can think of doing such a task. That makes
this Misra rule redundant because the next rule states "Unions shall
not be used"

I was just trying to find out if this could be done without the use of
Unions.

 

[Ian Collins]

Hello

I would like to create a test case that violates the following MISRA
C:2004 rule .

Misra Rule 18.2. An object shall not be assigned to an overlapping
object.
"The behaviour is undefined when two objects are created which have
some overlap in memory and one is copied to the other"

The sample I have created is
---------------------------------------------------------------
#include <string.h>

typedef char char_t;
Why?

char_t main(void)
{

int main(void).

char_t Buffer[]= "is this a violation?";
memcpy(&Buffer[5], &Buffer[10], 10); /*Violation, memory over lapped,
result will equal "is thviolation?tion?"*/

return(Buffer[5]);
}

-------------------------------------------------------------------------------------
However the rule relates to copying one object to another different
object where the two objects have some memory overlapping. It could
possibly be related to using unions.

Can anyone think of a way I can violate this rule??

How about this, assuming sizeof(int) = 4:

char stuff[6];

int* p1 = (int*)stuff;
int* p2 = (int*)&stuff[2];

*p1 = 42;

*p2 = *p1;

 

[hammer1234]

Why?

I am testing how well PC-LINT performs in detecting Violations of The
MISRA C2004 Guidlines. I have to create violations for every rule and
find out what Lint has to say about them. Therefore a simple typedef
such as

typedef char char_t

is required or an earlier rule will be violated.

 

[Richard Bos]

I am testing how well PC-LINT performs in detecting Violations of The
MISRA C2004 Guidlines. I have to create violations for every rule and
find out what Lint has to say about them. Therefore a simple typedef
such as

typedef char char_t

is required or an earlier rule will be violated.

*Boggle* MISRA C does not let you use normal C integer types, but
_requires_ them to be put behind an obfuscatory and completely useless
typedef? It defies belief... but if so, that ruleset is just wrong.

Richard