Overflowing Aside From Debugging: Addressing Undefined Behavior In C++ For Relia

by

Why Are Random Numbers Printing in the Terminal? A C++ Undefined Behavior Postmortem

Summary

A C++ is_palindrome() function that returns bool was called inside a std::cout stream expression, but the function had no return statement. The function returned a bool that reached the closing brace without ever returning a value, triggering undefined behavior. The “random numbers” (208, 192, 64, 0, etc.) were raw garbage values from the stack being interpreted as the return value — different every run.

Key takeaways:

  • bool-returning functions with no return statement produce undefined behavior in C++.
  • Streaming a missing or garbage return value to std::cout prints whatever bits happened to occupy the return register or stack slot.
  • The changing numbers across runs are a classic fingerprint of undefined behavior.

Root Cause

The function signature promises a bool return:

bool is_palindrome(std::string text) {
    // ... logic ...
    // NO return statement anywhere!
}

The function has two code paths (palindrome branch and else branch), and neither path returns a value. Additionally, main() streams this nonexistent return value:

std::cout << is_palindrome("madam") << "
";

What happens step by step:

  • is_palindrome("madam") executes and prints "madam is a palindrome! " to the terminal via the internal std::cout call
  • The function falls off the end of a non-void function without a return — this is undefined behavior per the C++ standard
  • The compiler, in the presence of undefined behavior, may return whatever bit pattern happens to be in the return register or stack location
  • That garbage bit pattern, interpreted under bool return semantics, gets implicitly converted and streamed to std::cout alongside the " " newline
  • Because the return register contents depend on previous stack activity, the values vary across executions (208, 192, 64, 0)

Why This Happens in Real Systems

  • C++ does not zero-initialize or default-initialize return values. Unlike Java or C#, there is no guaranteed “default return” for non-void functions.
  • The stack contains residual data from previous function calls. The register convention (e.g., EAX/RAX on x86) retains whatever was last written to it.
  • The C++ standard explicitly classifies this as undefined behavior (see [stmt.return] and [basic.start.main]). Compilers may assume this never happens and optimize accordingly, producing wildly unexpected results.
  • std::cout << with a bool uses operator<<(bool), which converts true→1 and false→0. However, with undefined behavior, the compiler may not even produce a meaningful bool value, explaining raw integers like 208 bypassing the normal true/false formatting.
  • Optimizations exacerbate this. With -O2, compilers often exploit undefined behavior aggressively, potentially eliminating entire branches or returning completely nonsensical values.

Common scenarios that trigger similar bugs:

  • Complex control flow with early returns but missing coverage on some paths
  • Refactoring that adds new branches but forgets to add the corresponding return
  • Copy-paste errors where the return in one branch is forgotten in the duplicated code
  • Missing return in switch statements where default (or some case) has no return

Real-World Impact

  • Nondeterministic test results — the program appears to “work” but produces inconsistent outputs across runs, making it extremely hard to reproduce
  • Security vulnerabilities — in production systems, leaking stack contents through return values can leak sensitive data (encryption keys, passwords, pointers)
  • Silent data corruption — in embedded systems or scientific computing, garbage return values propagate through calculations without any crash or obvious error
  • Compiler-dependent behavior — the same code may output 0 on one compiler version and crash on another, or silently corrupt memory on an embedded target
  • CI/CD false confidence — tests may pass on a specific compiler/optimization level but fail in production with different flags

Example or Code

Buggy Code

#include 
#include 

bool is_palindrome(std::string text) {
    std::string rev = text;
    std::reverse(rev.begin(), rev.end());
    if (text == rev) {
        std::cout << text << " is a palindrome!
";
    } else {
        std::cout << text << " is not a palindrome.
";
    }
    // MISSING return statement! Undefined behavior!
}

int main() {
    std::cout << is_palindrome("madam") << "
";
    std::cout << is_palindrome("ada") << "
";
    std::cout << is_palindrome("lovelace") << "
";
}

Fixed Code

#include 
#include 

bool is_palindrome(const std::string& text) {
    std::string rev = text;
    std::reverse(rev.begin(), rev.end());
    if (text == rev) {
        std::cout << text << " is a palindrome!
";
        return true;
    } else {
        std::cout << text << " is not a palindrome.
";
        return false;
    }
}

int main() {
    is_palindrome("madam");
    is_palindrome("ada");
    is_palindrome("lovelace");
}

Key fixes applied:

  • Added return true; and return false; on both branches, ensuring every path returns a defined bool
  • Removed std::cout << is_palindrome(...) pattern — the function already handles its own output, so streaming the return value was redundant and confusing
  • Changed parameter to const std::string& to avoid unnecessary copy (minor improvement, good practice)

How Senior Engineers Fix It

Senior engineers approach this systematically:

  • Enable all compiler warnings. -Wall -Wextra on GCC/Clang will directly warn about missing return statements. Treat -Werror as the default — every warning is an error.

    g++ -Wall -Wextra -Werror -Wreturn-type -o palindrome palindrome.cpp
    warning: no return statement in function returning non-void [-Wreturn-type]

  • Refactor the design to separate concerns. A function should either compute a value OR produce side effects (like printing), not both. The ideal refactor:

    bool is_palindrome(const std::string& text) {
  std::string rev = text;
  std::reverse(rev.begin(), rev.end());
  return text == rev;
}

void check_and_print(const std::string& text) {
if (is_palindrome(text)) {
std::cout << text << ” is a palindrome!
“;
} else {
std::cout << text << ” is not a palindrome.
“;
}
}

- **Use `[[nodiscard]]`** on return-value functions to catch discarded results at the call site.
- **Run static analysis tools** (cppcheck, Clang-Tidy, PVS-Studio) as part of the build pipeline — these catch missing returns, dead code, and other UB patterns automatically.
- **Write unit tests** that assert return values explicitly, catching cases where a function silently returns garbage.
- **Enable AddressSanitizer and UBSan** (`-fsanitize=undefined`) during testing — UBSan specifically traps undefined behavior at runtime.

## Why Juniors Miss It

**Junior developers miss this bug for several interconnected reasons:**

- **`cout <<` chaining masks the problem.** The syntax `std::cout << is_palindrome("madam")` looks like a normal print statement. Juniors see the palindrome message printing correctly and assume everything works — they don't realize the **return value is secretly being printed too**.

- **Non-void functions without returns often "work" on simple test cases.** Many compilers leave stale or zero values in the return register for simple programs, creating the illusion of correctness.

- **Undefined behavior doesn't always crash.** Juniors expect bugs to fail loudly. UB often produces **seemingly plausible but subtly wrong** results, which is far more dangerous.

- **The function mixes I/O and logic.** Because `is_palindrome()` both prints AND returns a value, juniors are confused about what `std::cout << is_palindrome(...)` actually does. They see the printed string and don't realize the `<<` operator is also appending the return value.

- **Warning messages are ignored or hidden.** Many beginners don't compile with warnings enabled, or treat warnings as non-critical. The `-Wreturn-type` warning has existed in GCC since the 1990s and would have caught this instantly.

- **No mental model of "return register."** Senior engineers understand that without an explicit `return`, the CPU register used for the return value contains whatever was left there by the last operation. Juniors often think "no return = nothing happens," when in reality **undefined behavior means anything can happen**.

**The fix is cultural, not just technical:** always compile with warnings as errors, enable sanitizers, write tests for return values, and separate computational logic from I/O side effects.

Leave a Comment