UpdatedAug 4, 2026

Undefined Behavior

Question Variations

"What is undefined behavior in C++?"
"Why can undefined behavior change between debug and release builds?"
"Does checking a result after undefined behavior make it safe?"
"Which tools help find undefined behavior?"

Why This Is Asked

Undefined behavior is a defining concern in systems C++. This question tests whether you understand why code that seems to work in one build is still incorrect, and how tools and safer abstractions reduce the risk.

Key Concepts

Undefined behavior has no required outcome under the C++ standard.
Common causes include out-of-bounds access, use-after-lifetime, signed overflow, and data races.
Optimizers may assume undefined behavior does not happen.
Sanitizers and warnings help find issues but cannot prove their absence.

Question Variations

“What is undefined behavior in C++?”
“Why can undefined behavior change between debug and release builds?”
“Does checking a result after undefined behavior make it safe?”
“Which tools help find undefined behavior?”

Answers by Technology

+ Add Variant

C++Improve this answer ✏️

Expected Answer (C++23)

Undefined behavior is an operation for which the C++ standard imposes no requirements. The program might appear to work, crash, produce an incorrect value, or be transformed unexpectedly by optimization. It is not a normal exception or reliably catchable runtime condition.

Examples include accessing an array out of bounds, dereferencing a dangling pointer, overflowing a signed integer, and a data race. Prevent it through strong ownership and bounds-aware APIs; use compiler warnings and runtime sanitizers to find bugs during development.

#include <array>

int main() {
    std::array<int, 2> values{1, 2};
    // values[2] = 3; // Undefined behavior: out-of-bounds access.

    values.at(1) = 3; // Bounds-checked; throws on an invalid index.
    return values[1] == 3 ? 0 : 1;
}

Why It Matters

Undefined behavior can undermine security, correctness, and portability in ways that evade normal testing. Knowing where it arises leads to designs that are both safer and easier for compilers to optimize correctly.

Common Mistakes

Treating a successful test run as proof that undefined behavior is harmless: The result can vary with input, compiler, optimization, or surrounding code.
Relying on signed-integer wraparound: Signed overflow is undefined; use checked logic or an appropriate unsigned/modular design when intended.
Assuming sanitizers catch every issue: They cover many important cases but depend on executed paths and enabled instrumentation.

Follow-up Questions

Why can an optimizer exploit undefined behavior? (Answer: It may assume valid programs never execute an undefined operation when transforming code.)
What tool helps detect out-of-bounds and use-after-free errors? (Answer: AddressSanitizer.)