Editing Undefined behavior (section)

== Benefits ==
Documenting an operation as undefined behavior allows compilers to assume that this operation will never happen in a conforming program. This gives the compiler more information about the code and this information can lead to more optimization opportunities.

An example for the C language:

<syntaxhighlight lang="c">
int foo(unsigned char x)
{
     int value = 2147483600;  /* assuming 32-bit int and 8-bit char */
     value += x;
     if (value < 2147483600)
        bar();
     return value;
}
</syntaxhighlight>

The value of <code>x</code> cannot be negative and, given that signed [[integer overflow]] is undefined behavior in C, the compiler can assume that <code>value < 2147483600</code> will always be false. Thus the <code>if</code> statement, including the call to the function <code>bar</code>, can be ignored by the compiler since the test expression in the <code>if</code> has no [[side effect (computer science)|side effects]] and its condition will never be satisfied. The code is therefore semantically equivalent to:

<syntaxhighlight lang="c">
int foo(unsigned char x)
{
     int value = 2147483600;
     value += x;
     return value;
}
</syntaxhighlight>

Had the compiler been forced to assume that signed integer overflow has ''[[Integer overflow|wraparound]]'' behavior, then the transformation above would not have been legal.

Such optimizations become hard to spot by humans when the code is more complex and other optimizations, like [[inlining]], take place. For example, another function may call the above function:

<syntaxhighlight lang="c">
void run_tasks(unsigned char *ptrx) {
    int z;
    z = foo(*ptrx);
    while (*ptrx > 60) {
        run_one_task(ptrx, z);
    }
}
</syntaxhighlight>

The compiler is free to optimize away the <code>while</code>-loop here by applying [[value range analysis]]: by inspecting <code>foo()</code>, it knows that the initial value pointed to by <code>ptrx</code> cannot possibly exceed 47 (as any more would trigger undefined behavior in <code>foo()</code>); therefore, the initial check of <code>*ptrx > 60</code> will always be false in a conforming program. Going further, since the result <code>z</code> is now never used and <code>foo()</code> has no side effects, the compiler can optimize <code>run_tasks()</code> to be an empty function that returns immediately. The disappearance of the <code>while</code>-loop may be especially surprising if <code>foo()</code> is defined in a [[interprocedural optimization|separately compiled object file]].

Another benefit from allowing signed integer overflow to be undefined is that it makes it possible to store and manipulate a variable's value in a [[processor register]] that is larger than the size of the variable in the source code. For example, if the type of a variable as specified in the source code is narrower than the native register width (such as <code>[[C data types#Basic types|int]]</code> on a [[64-bit]] machine, a common scenario), then the compiler can safely use a signed 64-bit integer for the variable in the [[machine code]] it produces, without changing the defined behavior of the code. If a program depended on the behavior of a 32-bit integer overflow, then a compiler would have to insert additional logic when compiling for a 64-bit machine, because the overflow behavior of most machine instructions depends on the register width.<ref>{{Cite web|url=https://gist.github.com/rygorous/e0f055bfb74e3d5f0af20690759de5a7#file-gistfile1-txt-L166|title = A bit of background on compilers exploiting signed overflow}}</ref>

Undefined behavior also allows more compile-time checks by both compilers and [[static program analysis]].{{citation needed|date=December 2019}}