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, which are part of the ISO C standard.

InC99 Section 6.5, Para. C997 \[[ISO/IEC 9899:1999|https://www.securecoding.cert.org/confluence/display/seccode/AA.+C+References#AA.CReferences-ISO%2FIEC98991999]\]  states that
\\C References#ISO/IEC 9899-1999]\] specifies those circumstances in which an object may or may not be aliased.

7. An object shall have its stored value accessed only by an lvalue expression that has one of
the following types: (78)

• 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.

(78) The intent of this list is to specify those circumstances in which an object may or may not be aliased.

These rules say that a program is invalid if you try to access a variable through a pointer of an incompatible type. This is happening in the following example, where a short is accessed through a pointer to an integer (the code assumes 16-bit shorts and 32-bit integers)Accessing an object by means of any other lvalue expression results in undefined behavior.

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.

#include <stdio.h>

int main()
{
    short a[2];

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

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

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

...

InWhen thetranslating casethis abovecode, thean compilerimplementation may assume that no access through an integer pointer can change the array {{a}}, consisting of shorts. ThusConsequently, {{printf()}} may be called with the original values of {{a\[0\]}} and {{a\[1\]}}. WhatThe reallyactual happensbehavior is up to the compiler implementation-defined and may change with architecture and optimization level.

Implementation Details

Recent versions of GCC turn on the option -fstrict-aliasing (which allows alias-based optimizations) by default with -O2. And some architectures then really 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 - cases of violation violations of aliasing rules when -fstrict-aliasing is active.

When GCC 3.4.6 compiles this code with optimization, it yields an executable that behaves like the following code:

#include <stdio.h>

int main()
{
    short a[2];

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

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

In other words, GCC 3.4.6 effectively removes the assignment.

Compliant Solution

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 objectTo fix the code above, you can use a union instead of a cast.

#include <stdio.h>

int main()
{
    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]);
    return 0;
}

This code example now reliably outputs Now the result will always be "2222 2222".

Risk Assessment

...