Array Out of Bounds in C++

Analogy categoryAnalogies

1. Intro

One of the most important safety gotchas in C++ is that built-in arrays do NOT perform any automatic bounds checking at runtime. If your code accesses an index outside the valid range of an array, C++ will not stop you, throw an exception, or reliably crash — it simply reads or writes whatever memory happens to sit at that address. This topic focuses entirely on understanding, recognizing, and avoiding this class of bug.

🏏

Cricket analogy: A scorer who keeps writing runs onto sheet rows beyond over 50 in a 50-over match without anyone stopping them mirrors how C++ arrays don't automatically stop you from writing past the last valid index.

2. Syntax

cpp

int arr[5] = {1, 2, 3, 4, 5};

// Valid indices are 0 through 4
arr[0];   // valid
arr[4];   // valid

arr[5];   // out of bounds — undefined behavior!
arr[-1];  // out of bounds — undefined behavior!

3. Explanation

For int arr[5];, the only valid indices are 0 through 4. Writing arr[5] or arr[-1] steps outside the memory that was actually reserved for the array. Because C++ built-in arrays carry no runtime record of their own size or bounds, the compiler and runtime cannot detect this mistake for you — the expression arr[5] compiles perfectly fine and simply computes an address just past the end of the array, then reads or writes whatever data happens to live there.

🏏

Cricket analogy: For a 5-slot batting order int arr[5], valid positions are 1 through 5 (indices 0-4); writing to a nonexistent 'position 6' slot compiles fine on a careless scoreboard system but silently corrupts whatever data sits in the next memory bay, just like arr[5] in C++.

**Undefined behavior, not a guaranteed error.** Accessing an out-of-bounds array index does NOT reliably crash your program or print an error message. It might silently corrupt an unrelated variable, appear to "work" during testing, or crash unpredictably — sometimes much later in execution, far from the actual bug. This unpredictability is exactly what makes out-of-bounds access so dangerous: your program can look correct while quietly corrupting memory.

Because the compiler cannot always catch this at compile time (especially when the index is computed at runtime, e.g. from user input or a loop variable), the responsibility falls entirely on the programmer. Common causes include off-by-one errors in loop conditions (using <= instead of < against the array size), forgetting that the last valid index is size - 1, and looping past an array's bounds when processing user input. Safer alternatives that add automatic bounds checking include using std::vector with its .at() member function, which throws a catchable exception on an invalid index, or carefully validating any index derived from external input before using it.

🏏

Cricket analogy: A scorer using <= instead of < when checking overs bowled might record a nonexistent 51st over in a 50-over match — the classic off-by-one bug — whereas a modern DRS-style system with built-in validation, like std::vector::at(), would flag the invalid over immediately with a clear alert.

4. Example

cpp

#include <iostream>
using namespace std;

int main() {
    int arr[5] = {10, 20, 30, 40, 50};

    // Common off-by-one bug: loop condition should be i < 5, not i <= 5
    for (int i = 0; i <= 5; i++) {
        cout << "arr[" << i << "] = " << arr[i] << endl;
    }

    return 0;
}

5. Output

text

arr[0] = 10
arr[1] = 20
arr[2] = 30
arr[3] = 40
arr[4] = 50
arr[5] = <undefined/garbage value, behavior is not guaranteed>

6. Key Takeaways

C++ built-in arrays perform NO automatic bounds checking at runtime.
Accessing an index outside 0 to size - 1 is undefined behavior, not a guaranteed crash or compile error.
Undefined behavior can silently corrupt memory or appear to work, making these bugs hard to detect during testing.
Off-by-one loop conditions (using <= instead of <) are a very common cause; validating indices and using std::vector::at() are safer alternatives.