Identifying Undefined and Implementation-Dependent Behavior in C

Welcome back. Last lesson, you separated an expression’s type from an object’s lifetime and learned why structure layout cannot be guessed from source alone. Today, you’ll make a sharper distinction: does C define this operation, does the implementation choose and document its behavior, or does the program have no language-level guarantee at all?

This distinction matters in a code review or interview because “it worked on my machine” answers none of those questions. Plan on about 40 minutes, including a short compiler experiment on your Linux VM.

Four labels for reading a C program

The C standard describes an abstract machine: a model of what a conforming program means, independent of the instructions a compiler eventually emits. When you inspect a line of C, classify its behavior before predicting a value.

“Implementation-dependent” is a useful informal warning, but implementation-defined and unspecified are different technical labels. For example, the size of int in bytes depends on the implementation. The order of evaluation of function arguments is generally unspecified. Neither fact, by itself, makes a program undefined.

A reliable interview response gives the condition as well as the label. “This is UB” is less informative than “If p is null when *p is evaluated, that execution has UB; otherwise this particular access may be valid.”

Find the operation that breaks the guarantee

Last lesson’s lifetime example illustrates one category: accessing an automatic object after its lifetime ends is not a way to retrieve an old value. Similar reasoning applies to bounds. Given int data[3];, data + 3 is a valid one-past-the-end pointer. Forming data + 4 is outside the permitted pointer-arithmetic range, and dereferencing data + 3 is invalid. A plausible numerical address does not change either rule.

Null checks must likewise guard the first access, not merely a later one:

The condition on customAssert() matters. The declaration shown does not tell us whether it returns. We can establish that the function has an undefined path, not that every call is undefined. A safe implementation would either return or report an error on the null path, or use an assertion function whose non-returning behavior is genuinely guaranteed by its interface and implementation.

Other frequent triggers are reading an uninitialized ordinary local value, accessing freed storage, dividing an integer by zero, and overflowing a signed integer. For these, do not supply a “likely output” as though it were C’s answer.

There is a particularly important boundary between unspecified order and UB:

combine(mark(1), mark(2)); /* argument evaluation order unspecified */

int i = 0;
combine(i++, i++);         /* UB: unsequenced modifications of i */

In the first call, mark(1) and mark(2) can execute in either order; if they print, the order of those messages can vary. In the second, choosing an argument order does not rescue the expression: the two modifications of i are unsequenced relative to each other. Split them into separate full expressions if their order matters.

Arithmetic: portable result, documented choice, or UB?

Unsigned arithmetic has defined wraparound in its unsigned type; signed arithmetic does not. If x is an int holding INT_MAX, evaluating x + 1 has UB. On a machine whose addition instruction wraps, you might observe a negative result in one build, but that observation is not a C guarantee.

This is more than a theoretical objection. An optimizer can reason that, on executions with defined behavior, x + 1 is greater than x. A check written after a potentially overflowing addition may therefore fail to serve as the protection its author intended.

Pointer arithmetic and shifts have equally sharp boundaries. The following reference is useful when a short interview snippet combines them.

For shifts, inspect the promoted left operand’s width. A negative count or a count at least that width is UB. In contrast, with a valid count, right-shifting a negative signed int is an implementation-defined case in C11. When working with bit masks or storage-protocol fields, unsigned types make the intended bit operations easier to state precisely—but unsigned wraparound still needs an explicit check when wraparound would corrupt a length or offset.

Verify classifications on your Linux VM

Save this as c_rules.c. Its ordinary path contains a defined one-past-pointer use, implementation-dependent observations, and an unspecified argument order. A separate command-line path deliberately triggers signed overflow so a sanitizer can report it.

#include <limits.h>
#include <stdio.h>

static int mark(int value)
{
    printf("mark %d\n", value);
    return value;
}

static int combine(int a, int b)
{
    return 10 * a + b;
}

int main(int argc, char **argv)
{
    int data[3] = {7, 8, 9};
    int *past = data + 3;

    printf("last element: %d\n", past[-1]);
    printf("sizeof(int): %zu\n", sizeof(int));
    printf("negative right shift: %d\n", -3 >> 1);
    printf("combined: %d\n", combine(mark(1), mark(2)));

    if (argc > 1 && argv[1][0] == 'o') {
        volatile int max = INT_MAX;
        printf("overflow: %d\n", max + 1);
    }

    return 0;
}

Compile and run it in your VM:

cc -std=c11 -O1 -g -Wall -Wextra -Wpedantic \
   -fsanitize=undefined -fno-sanitize-recover=undefined \
   c_rules.c -o c_rules
./c_rules
./c_rules overflow

On the ordinary run, past[-1] accesses data[2], so it prints 9; *past would instead dereference the one-past pointer. Your implementation determines the reported sizeof(int) and documents its choice for the negative signed right shift. The two mark messages may appear in either order, while combine still receives the values 1 and 2.

The second run should report signed integer overflow and stop under these sanitizer options. The volatile local helps keep the addition as a runtime operation for this demonstration; volatile does not make overflow safe. UBSan reports faults on paths you execute and that it instruments. A clean run is not proof that every possible path is valid.

The repair is to check before adding:

if (max == INT_MAX) {
    fputs("cannot increment max\n", stderr);
    return 1;
}
printf("incremented: %d\n", max + 1);

That ordering is the useful production habit: establish an operation’s preconditions before performing it. It also gives you a concise way to explain a fix aloud, rather than merely naming a defect.

Key takeaways

Classify a C expression by its guarantee, then state the inputs and path on which your classification holds. Unspecified order allows a choice among valid executions; implementation-defined behavior requires a documented choice; UB provides no promised result for an execution that reaches it. Bounds, object lifetime, unsequenced modifications, and signed overflow are especially worth checking before predicting output.

Next, you’ll use this discipline to build small heap-allocated C objects with clear ownership, cleanup, and error paths—where avoiding invalid accesses starts with a sound design rather than a sanitizer report.