Modifying a variable through a pointer of an incompatible type can lead to unpredictable results. This is often caused by a violation of aliasing rules. C11, Section 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.

Accessing an object by means of any other lvalue expression results in undefined behavior . See undefined behavior 34 of Annex J.

Noncompliant Code Example

The programmer in this noncompliant code example is attempting to read from a different union member than the one most recently written to; this is known as "type-punning."

union a_union {
  int i;
  double d;
};

int f() {
  a_union t;
  int *ip;
  t.d = 3.0;
  ip = &t.i;
  return *ip;
}

However, instead of reading directly from union member, it assigns a pointer ip to reference the integer value and returns the value referenced by the pointer. Unfortunately, this is a violation of the strict aliasing rules and in this case the compiler may determine that ip refers to some other value than the value stored by t.i and return a value other than the expected value.

Noncompliant Code Example

In this noncompliant code example, access by taking the address, casting the resulting pointer and dereferencing the result has undefined behavior, even if the cast uses a union type.

union a_union {
  int i;
  double d;
};

int f() {
  double d = 3.0;
  return ((union a_union *) &d)->i;
}

Because of optimization, the function f() may return something other than the expected value.

Compliant Solution

Type-punning is allowed provided the memory is accessed through the union type. This compliant solution returns the expected value.

union a_union {
  int i;
  double d;
};
          
int f() {
  a_union t;
  t.d = 3.0;
  return t.i;
} 

Noncompliant Code Example

In this noncompliant code example, an array of two shorts is treated as an integer and assigned an integer value. The resulting value of the two shorts is undefined.

short a[2];

a[0]=0x1111;
a[1]=0x1111;

*(int *)a = 0x22222222;  /* violation of aliasing rules */

printf("%x %x\n", a[0], a[1]);

When translating this code, an implementation can assume that no access through an integer pointer can change the array a, consisting of shorts. Consequently, printf() may be called with the original values of a[0] and a[1]. The actual behavior is implementation-defined and can change with optimization level.

Implementation Details

Recent versions of GCC turn on the option -fstrict-aliasing (which allows alias-based optimizations) by default with -O2. Some architectures then print "1111 1111" as a result. Without optimization, the executable will generate the "expected" output "2222 2222".

To disable optimizations based on alias-analysis for faulty legacy code, the option -fno-strict-aliasing can be used as a workaround. The option -Wstrict-aliasing (which is included in -Wall) warns about some,but not all, violations of aliasing rules when -fstrict-aliasing is active.

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.

union {
  short a[2];
  int i;
} u;

u.a[0]=0x1111;
u.a[1]=0x1111;

u.i = 0x22222222;

printf("%x %x\n", u.a[0], u.a[1]);

This code example now reliably outputs "2222 2222".

Risk Assessment

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

Related Guidelines

ISO/IEC 9899:2011 Section 6.5, "Expressions"

ISO/IEC TR 17961 Accessing an object through a pointer to an incompatible type [ptrcomp]

Bibliography

GCC Known Bugs C bugs, Aliasing issues while casting to incompatible types
GCC Manual
[Walfridsson 2003] Krister Walfridsson. Aliasing, pointer casts and gcc 3.3 Aliasing issue. August, 2003.
[Acton 2006] Mike Acton. Understanding Strict Aliasing. June 01, 2006.