4 Surprising Ways C Language 'Undefined Behaviour' Can Secretly Break Your Code

Introduction: The Silent Minefield in Everyday C Code

The C programming language remains the undisputed foundation of low-level systems engineering, granting software developers raw execution speed and unmediated access to hardware memory. However, this unmatched efficiency relies on a fundamental design trade-off: the language specification deliberately leaves room for "Undefined Behaviour" (UB). In simple terms, Undefined Behaviour refers to any program state or operation for which the C standard imposes no requirements whatsoever on the compiler's output.

When a program triggers Undefined Behaviour, the C standard frees the compiler from all execution guarantees. The resulting binary may crash unexpectedly, silently corrupt critical memory structures, execute nonsensical machine instructions, or produce erratic output that changes across different optimization passes. This article examines four counter-intuitive case studies of Undefined Behaviour in C—exploring the underlying machine logic, compiler assembly output, and system execution mechanics that every systems engineer must master.

Division by Zero: Integer Fatalities vs. Floating-Point IEEE Exceptions

Dividing an integer expression by zero is strictly classified as Undefined Behaviour in standard C. When compiling C code with GCC targeting a UNIX/Linux environment, executing an integer division by zero causes the hardware CPU to raise an interrupt. The Linux kernel intercepts this exception and terminates the offending process by issuing a signal, resulting in the familiar terminal error: floating point exception (core dumped).

#include <stdio.h>
int main(void) {
    int x = 0;
    double y = 10 / x; // UB: Integer division by zero before assignment
    printf("Result: %lf\n", y);
    return 0;
}

In contrast, floating-point division by zero exhibits completely deterministic, well-defined behavior under modern IEEE 754 arithmetic standards supported by standard C implementations. When dividing a finite, non-zero floating-point variable (float or double) by 0.0, the operation does not crash the process. Instead, it evaluates safely to positive infinity (+inf) or negative infinity (-inf), depending on the sign of the numerator. Furthermore, dividing 0.0 / 0.0 yields NaN (Not-a-Number).

#include <stdio.h>
int main(void) {
    double numerator = 10.0;
    double denominator = 0.0;
    
    double y = numerator / denominator; // Well-defined under IEEE 754: evaluates to +inf
    printf("Result: %lf\n", y);
    return 0;
}

The C99 standard specification strictly defines the integer arithmetic constraint:

"The result of the / operator is the quotient from the division of the first operand by the second; the result of the % operator is the remainder. In both operations, if the value of the second operand is zero, the behaviour is undefined."

This contrast frequently surprises developers. While floating-point hardware and software specifications safely capture mathematical infinity without interrupting process control flow, integer division by zero completely violates C standard operational semantics and immediately halts process execution at runtime.

Bitwise Shift Traps: Oversized and Negative Bit Shifts

Bitwise shift operators (<< and >>) operate on the underlying binary representations of integer variables. Under standard execution bounds, the shift operation is defined mathematically:

• Left Shift (E1 \ll E2): For unsigned types, this evaluates to E1 \times 2^{E2} (reduced modulo one more than the maximum value representable in the result type).
• Right Shift (E1 \gg E2): Evaluates to the integral quotient of E1 / 2^{E2}.

However, executing a shift operation where the shift count E2 is negative, or where E2 is greater than or equal to the bit-width of the promoted left operand E1, immediately invokes Undefined Behaviour.

#include <stdio.h>
#include <stdint.h>
int main(void) {
    uint32_t a = 0xFFFFFFFF;
    uint32_t res_right = a >> 35; // UB: Shift count (35) >= bit-width (32)
    int32_t b = 0x0FFFFFFF;
    int32_t res_left = b << 34;   // UB: Oversized left shift
    uint32_t c = 0x0FFFFFFF;
    uint32_t res_neg = c << -2;   // UB: Negative shift count
    printf("a >> 35: %u\n", res_right);
    printf("b << 34: %X\n", res_left);
    printf("c << -2: %X\n", res_neg);
    return 0;
}

Developers often falsely assume that shifting a 32-bit integer right by 35 bits will automatically evaluate to 0. In practice, compilers like GCC emit build warnings and yield unexpected garbage values.

The primary cause lies in underlying CPU architecture mechanics. On x86 processors, the hardware instruction set implements bit shifts by masking the shift count operand with 0x1F (5 bits) for 32-bit integers. Consequently, attempting to shift a 32-bit integer by 35 bits causes the CPU hardware to compute 35 & 0x1F, actually performing a shift of 3 bit positions.

The C99 standard explicitly mandates these right-operand boundary limits:

"If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behaviour is undefined."

Relying on oversized or negative bit shifts introduces silent hardware-dependent anomalies into application logic, breaking cross-platform portability.

Null Pointer Dereferencing: Compiler Behavior and OS Interception

In standard C, NULL is a macro constant representing an integer constant value 0 explicitly or implicitly cast to void*, designating a pointer that points to no valid memory object. Attempting to dereference a NULL pointer (such as writing *p = 10 when p == NULL) triggers Undefined Behaviour.

#include <stdio.h>
int main(void) {
    int *p = NULL;
    /* Dereferencing the NULL pointer */
    *p = 10; // UB: Indirection on null pointer
    return 0;
}

To prioritize execution speed and eliminate runtime overhead, compilers such as GCC do not inject automated null-check verification logic before pointer indirection instructions. Analyzing the generated x86 assembly code for the snippet above demonstrates this low-level compiler behavior:

movq    $0, -8(%rbp)        # Store NULL (0) into local pointer 'p'
movq    -8(%rbp), %rax      # Load pointer address into %rax register
movl    $10, (%rax)         # Directly attempt to write 10 to address in %rax

GCC directly emits movl $10, (%rax) without verifying whether %rax contains zero. Handling the consequence of dereferencing address zero is passed down entirely to the runtime environment:

• OS-Based Systems (Linux/UNIX): When the CPU executes the store instruction to virtual address 0x0, the MMU hardware triggers a page fault. The Linux kernel's page fault handler checks the process page tables, determines that address zero is unmapped, and sends a SIGSEGV (Segmentation Fault) signal to terminate the process.
• Bare-Metal Embedded Systems: In embedded environments lacking virtual memory protection and operating system page fault handlers, address zero often maps directly to physical RAM or flash memory. Executing *p = 10 quietly overwrites physical memory at address 0x0, causing silent data corruption, erratic execution, or system lockups.

The C99 standard defines unary indirection limitations concisely:

"If an invalid value has been assigned to the pointer, the behaviour is undefined."

By omitting mandatory runtime null checks, C compilers achieve maximum execution speed, placing full responsibility for pointer validation on developer discipline and operating system memory protection mechanisms.

Array Bounds Violations: Silent Memory Corruption

Unlike memory-safe runtimes, C compilers perform no implicit bounds checking on array indexing operations. Accessing or writing to an array index outside its declared boundary—such as writing to index 5 of a 5-element array indexed 0 through 4—violates C standard constraints and invokes Undefined Behaviour.

#include <stdio.h>
#define MAX 5
int main(void) {
    int a[MAX] = {1, 2, 3, 4, 5};
    // Reading out-of-bounds: Returns arbitrary garbage
    printf("a[5]: %d\n", a[5]);
    // Writing out-of-bounds: Silently overwrites memory
    a[5] = 6;
    printf("a[5]: %d\n", a[5]);
    return 0;
}

The operational side-effects of array bounds violations vary significantly depending on the target system hardware and OS environment:

• Non-OS Embedded Systems: Out-of-bounds writes directly alter adjacent physical memory addresses. If those addresses store critical system variables or register states, the write instantly corrupts them, leading to severe data loss or total system crashes.
• OS-Based Systems: Reading past array bounds reads adjacent stack or heap memory, returning arbitrary garbage data. Writing past array bounds causes a buffer overflow that overwrites neighboring process variables.

A critical technical nuance is why small array overflows do not immediately trigger a segmentation fault under modern operating systems. OS kernel memory managers allocate virtual memory in multi-kilobyte blocks known as pages (typically 4 KB pages). When a small local array overflows by a few bytes, the adjacent memory write usually lands within the same allocated 4 KB process page block. Consequently, the write succeeds silently without triggering an MMU fault, corrupting stack frame data without immediate detection. A SIGSEGV only occurs if the array index extends far enough to cross into an unallocated or read-only memory page boundary.

As emphasized in the primary context:

"Unlike some other languages like Java, checking of array bounds is not present in the C language; it is all up to the programmer to take care of it."

GCC compiles out-of-bounds array reads and writes cleanly without emitting build errors, even when compiled with full warning flags like -Wall. Because standard compilation tools silently pass these boundary violations, engineering teams must deploy advanced static analysis tools (such as PVS-Studio) that utilize data-flow analysis and abstract interpretation to catch off-by-one errors and array buffer overflows before code reaches production.

Conclusion: Master C's Rules Before They Master You

The C language delivers extraordinary hardware performance precisely because its compilers operate on the trust assumption that code strictly adheres to the language standard. When a program strays into Undefined Behaviour—whether through integer division by zero, invalid bit shifts, null pointer dereferences, or array bounds violations—the compiler withdraws all execution safety guarantees.

Understanding the underlying low-level mechanics of Undefined Behaviour transforms subtle runtime anomalies into predictable software behavior. Do your current C codebase engineering practices rely on dangerous execution assumptions, or are you utilizing automated static analysis and memory protection tools to catch hidden undefined behaviour before deployment?

For all 2026 published articles list: click here: 

…till the next post, bye-bye & take care