...

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

Noncompliant Code Example

In this 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.

...

In the case above, the compiler may assume that no access through an integer pointer can change the array {{a}}, consisting of shorts. Thus, {{printf}} may be called with the original values of {{a\[0\]}} and {{a\[1\]}}. What really happens is up to the compiler and may change with architecture and optimization level.

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 work-aroundworkaround. The option -Wstrict-aliasing (which is included in -Wall) warns about some - but not all - cases of violation of aliasing rules when -fstrict-aliasing is active.

When GCC 3.4.6 compiles this code with optimization, it yeilds 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.

...

Optimizing for performance can lead to such 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.

...