...
This problem is often caused by a violation of aliasing rules. The C Standard, 6.5, paragraph 7 [ ISO/IEC 9899:20112024 ], specifies those circumstances in which an object may or may not be aliased.
An object shall have its stored value accessed only by an lvalue expression that has one of the following types:
- a type compatible with the effective type of the object,
- a qualified version of a type compatible with the effective type of the object,
- a type that is the signed or unsigned type corresponding to compatible with the underlying type of the effective type of the object, a type that is
- the signed or unsigned type corresponding to compatible with a qualified version of the underlying type of the effective type of the object,
- an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union), oror
- a character type.
Accessing an object by means of any other lvalue expression (other than unsigned char
) is undefined behavior 3736.
Noncompliant Code Example
...
When GCC 3.4.6 compiles this code with optimization, the assignment through the aliased pointer is effectively eliminated.
Compliant Solution
...
This compliant solution uses a union
type that includes a type compatible with the effective type of the object:
...
If the member used to read the contents of a union object is not the same as the member last used to store a value in the object, the appropriate part of the object representation of the value is reinterpreted as an object representation in the new type as described in 6.2.6 (a process sometimes called “type punning”). This might be a trap representation.
The call to printf()
typically outputs "2222 2222". However, there is no guarantee that this will be true; the object representations of a
and i
are unspecified and need not be compatible in this way, despite this operation being commonly accepted as an implementation extension. (See unspecified behavior 11.)
Compliant Solution (memcpy)
Noncompliant Code Example
In this noncompliant code example, a gadget
object is allocated, then realloc()
is called to create a widget
object using the memory from the gadget
object. Although reusing memory to change types is acceptable, accessing the memory copied from the original object is undefined behavior.This compliant solution uses memcpy
to convert the short
s to an int
:
Code Block | ||||
---|---|---|---|---|
| ||||
#include <stdio<stdlib.h> #include <string.h> void func(void)struct gadget { short a[2]int i; a[0]=0x1111double d; a[1]=0x1111char *p; }; struct widget int{ i =char 0x22222222*q; memcpy(a, &i, sizeof a); printf("%x %x\n", a[0], a[1]); } |
A good optimizing compiler will recognize the use of memcpy
and will emit code just as fast as the union
approach.
Noncompliant Code Example
In this noncompliant code example, a gadget
object is allocated, then realloc()
is called to create a widget
object using the memory from the gadget
object. Although reusing memory to change types is acceptable, accessing the memory copied from the original object is undefined behavior.
Code Block | ||||
---|---|---|---|---|
| ||||
#include <stdlib.h> struct gadget { int i; double d; char *p; }; struct widget { char *q; int j; double e; }; void func(void) { struct gadget *gp; struct widget *wp; gp = (struct gadget *)malloc(sizeof(struct gadget)); if (!gp) {int j; double e; }; void func(void) { struct gadget *gp; struct widget *wp; gp = (struct gadget *)malloc(sizeof(struct gadget)); if (!gp) { /* Handle error */ } /* ... Initialize gadget ... */ wp = (struct widget *)realloc(gp, sizeof(struct widget)); if (!wp) { free(gp); /* Handle error */ } /* ... Initialize gadgetif (wp->j == 12) { /* ... */ wp} = (struct widget *)realloc(gp, sizeof(struct widget));/* ... */ if free(!wp) { free(gp); /* Handle error */ } if (wp->j == 12) { /* ... */ } /* ... */ free(wp); } |
Compliant Solution
This compliant solution reuses the memory from the gadget
object but reinitializes the memory to a consistent state before reading from it:
;
} |
Compliant Solution
This compliant solution reuses the memory from the gadget
object but reinitializes the memory to a consistent state before reading from it:
Code Block | ||||
---|---|---|---|---|
| ||||
#include <stdlib.h>
#include <string.h>
struct gadget {
int i;
double d;
char *p;
};
struct widget {
char *q;
int j;
double e;
};
void func(void) {
struct gadget *gp;
struct widget *wp;
gp = (struct gadget *)malloc(sizeof (struct gadget));
if (!gp) {
/* Handle error */
}
/* ... */
wp = (struct widget *)realloc(gp, sizeof(struct widget));
if (!wp) {
free(gp);
/* Handle error */
}
memset(wp, 0, sizeof(struct widget));
/* ... Initialize widget ... */
if (wp->j == 12 | ||||
Code Block | ||||
| ||||
#include <stdlib.h> #include <string.h> struct gadget { int i; double d; char *p; }; struct widget { char *q; int j; double e; }; void func(void) { struct gadget *gp; struct widget *wp; gp = (struct gadget *)malloc(sizeof (struct gadget)); if (!gp) { /* Handle error... */ } /* ... */ wp = (struct widget *)realloc(gp, sizeof(struct widget)); if (!wp) { free(gp); /* Handle error */ } memset(wp, 0, sizeof(struct widget)); /* ... Initialize widget ... */ if (wp->j == 12) { /* ... */ } /* ... */ free(wp); }free(wp); } |
Noncompliant Code Example
According to the C Standard, 6.7.67.2 3 [ISO/IEC 9899:20112024], using two or more incompatible arrays in an expression is undefined behavior. (See also undefined behavior 7673.)
For two array types to be compatible, both should have compatible underlying element types, and both size specifiers should have the same constant value. If either of these properties is violated, the resulting behavior is undefined.
...
Most compilers will produce a warning diagnostic if the two array types used in an expression are incompatible.
Compliant Solution
In this compliant solution, b
is declared to point to an array with the same number of elements as a
, satisfying the size specifier criterion for array compatibility:
...
Tool | Version | Checker | Description | |||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
LDRA tool suiteCppcheck Premium |
| LDRA
| LDRA
| 94 S, 554 Spremium-cert-exp39-c | Partially implemented | |||||||||||||||||||||||||||
Helix QAC |
| C0310, C0751, C3305 C++3017, C++3030, | Parasoft C/C++ | test3033 | ||||||||||||||||||||||||||||
Klocwork |
| Parasoft
| Parasoft_V | CERT_C-EXP39-a | There shall be no implicit conversions from integral to floating type | Polyspace Bug Finder | ||||||||||||||||||||||||||
Include Page | Polyspace Bug Finder_V | Polyspace Bug Finder_V | Checks for cast to pointer pointing to object of different type (rule partially covered) | PRQA QA-C | ||||||||||||||||||||||||||||
Include Page | PRQA QA-C_v | PRQA QA-C_v | 0310, 0751, 3305 | Partially implemented | PRQA QA-C++ | |||||||||||||||||||||||||||
Include Page | cplusplus:PRQA QA-C++_V | cplusplus:PRQA QA-C++_V | 3017, 3030, 3033MISRA.CAST.FUNC_PTR.2012 | |||||||||||||||||||||||||||||
LDRA tool suite |
| 94 S, 554 S | Partially implemented | |||||||||||||||||||||||||||||
Parasoft C/C++test |
| CERT_C-EXP39-a | There shall be no implicit conversions from integral to floating type | |||||||||||||||||||||||||||||
Polyspace Bug Finder |
| Checks for cast to pointer pointing to object of different type (rule partially covered) | ||||||||||||||||||||||||||||||
PVS-Studio |
| V580 |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
...
[Acton 2006] | "Understanding Strict Aliasing" |
GCC Known Bugs | "C Bugs, Aliasing Issues while Casting to Incompatible Types" |
[ISO/IEC 9899:20112024] | 6.5, "Expressions" 6.7.67.23, "Array Declarators" |
[Walfridsson 2003] | Aliasing, Pointer Casts and GCC 3.3 |
...