Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Merged in contents from ARR34-C

Modifying a variable through a pointer of an incompatible type (other than unsigned char) can lead to unpredictable results. Subclause 6.2.7 of the C standard mentions that two types may be distinct yet compatible, and addresses precisely when two distinct types are compatible.

 This problem is often caused by a violation of aliasing rules. The C Standard, subclause 6.5, paragraph 7 [ISO/IEC 9899:2011], 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 the effective type of the object,
  • a type that is the signed or unsigned type corresponding to a qualified version 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), or
  • a character type.

...

Code Block
bgColor#ccccff
langc
#include <float.h>
#include <math.h>
#include <stdio.h>
 
void f(void) {
  float f = 0.0f;
  f = nextafterf(f, FLT_MAX);
  printf("float is %f\n", f);
}

 

Noncompliant Code Example

...

Code Block
bgColor#ccccff
langc
#include <stdlib.h>
#include <string.h>
 
struct gadget {
  int i;
  double d;
  char *p;
};
 
struct widget {
  char *q;
  int j;
  double e;
};
 
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));
if (wp->j == 12) {
  /* ... */
}

Noncompliant Code Example

According to subclause 6.7.6.2 of the C Standard [ISO/IEC 9899:2011], using two or more incompatible arrays in an expression results in undefined behavior. See also undefined behavior 76 of Appendix J.

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.

In this noncompliant code example, the two arrays a and b fail to satisfy the equal size specifier criterion for array compatibility. Because a and b are not equal, writing to what is believed to be a valid member of a might exceed its defined memory boundary, resulting in an arbitrary memory overwrite.

Code Block
bgColor#FFCCCC
langc
enum { ROWS = 10, COLS = 15 };
 
void func(void) {
  int a[ROWS][COLS];
  int (*b)[ROWS] = a;
}

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:

Code Block
bgColor#ccccff
langc
enum { ROWS = 10, COLS = 15 };
 
void func(void) {
  int a[ROWS][COLS];
  int (*b)[COLS] = a;
}

Risk Assessment

Optimizing for performance can lead to aliasing errors that can be quite difficult to detect. Furthermore, as in the preceding example, unexpected results can lead to buffer overflow attacks and/or bypassing security checks and/or unexpected execution.

...

ISO/IEC TS 17961Accessing an object through a pointer to an incompatible type [ptrcomp]
MITRE CWECWE-119, Failure to constrain operations within the bounds of an allocated memory buffer

Bibliography

[Acton 2006]"Understanding Strict Aliasing"
GCC Known Bugs"C Bugs, Aliasing Issues while Casting to Incompatible Types"
GCC Manual 
[ISO/IEC 9899:2011]Subclause 6.5, "Expressions"
Subclause 6.7.6.2, "Array Declarators"
[Walfridsson 2003]Aliasing, Pointer Casts and GCC 3.3

 

...