Out-of-Bounds Access

Indexing Past the End of Arrays

Real-World Undefined Behavior

To understand what happens when you access an array out of bounds, we need to talk about undefined behavior, but to get a sense of what that means, let's start with a real-world example.

Suppose you're driving a car, and you've been given the following map, with strict instructions to “stay on the road”:

You're driving along, and you see a shortcut that looks like it will save you some time. You're tempted to take it, but then you remember the instructions you were given: “stay on the road”. So you keep driving and arrive safely at your destination. But what would have happened if you'd tried to take that shortcut? You don't know! No one has said what will happen, so the consequences are not defined.

Languages like Python or Java like to define what happens when your program breaks the rules. So, in this situation they might say “we have installed guardrails on the road so if you try to drive off the road, you'll just bounce back onto the road”. Or they might have installed guardrails such that if your car touches the rails it will shut itself off and you'll need to be towed.

But installing guardrails is time consuming and expensive. Most roads don't have guardrails—you're just expected to drive properly and stay on the road. If you don't, you'll face the consequences, whatever they are. That's what it means to have undefined behavior. And that's the approach taken by C++—it expects you to follow the rules, and if you don't, it doesn't promise to protect you from the consequences, or even say what the consequences will be.

Perhaps the reason the road curves is that there is a lake in the way…

Or perhaps there's a cliff… But even if there was a dirt road through private property, perhaps a farm, and you drove through it fine three times, the fourth time you might get shot at by the farmer, or hit a closed gate, or get stuck in the mud.

Breaking the rules and getting away with it once doesn't mean you'll get away with it again. And that's what it means to have undefined behavior.

Breaking Array-Access Rules

In Java and Python, if you try to access an array at an index that doesn't exist, there is a predictable outcome (e.g., in Java, an ArrayIndexOutOfBoundsException will be thrown). For that predictable outcome to happen, there has to be some code (that you didn't write!) that double checks whether the index is in bounds and then either gets the item or throws the exception accordingly.

The C++ standard simply says “all array accesses must be in bounds”. If you break that rule, the consequences are not defined.

Most implementations of C++ make no special effort to check whether you're breaking the rules because that would take valuable time. They just do whatever is easiest and fastest, under the assumption that your program is following the rules. And, like driving off the road, if you break the rules, you might get away with it sometimes, but other times subtle damage will be done that you won't notice right away (e.g., some damage to the underside of your car, or subtle data corruption), and sometimes something catastrophic will happen immediately (e.g., your car catches fire, or your program scribbles over important data or crashes).

The practical upshot is that if C++ says “The consequences of accessing outside the bounds of an array are undefined” what it's really saying is “There is a hard rule: you must never access outside the bounds of an array.” If you break the rule, the consequences are allowed to be arbitrarily bad. You should certainly never write code that knowingly violates C++'s rules on the basis that the undefined behavior seems to be benign because “nothing bad seemed to happen” when you tried it a few times.

Consider this code snippet:

int x = 444;
int a[3]{1, 2, 3};
int y = 555;
cout << a[3] << endl;

Typical Behavior

int x = 444;
int a[3]{1, 2, 3};
int y = 555;
cout << a[3] << endl;

Key Ideas:

• Remember that a[3] means *(a +3), the memory address of the fourth element, if it exited.
• So the least-effort outcome is to interpret whatever bits are at that address as an int and return that value!
• Remember that variables in memory on a real machine need not be arranged in the same order as our memory model!

Segmentation Faults

If your program tries to access memory outside of its allocated region, the operating system will immediately shut the program down. This error is called a segmentation fault, or “segfault” for short.

A common cause for segmentation faults is accessing an array wayyyyyy out of bounds.

Segmentation fault errors can be very cryptic. Your program just stops (“crashes”) and you get a message that basically just says “Segmentation fault”—no line number, no context, nothing. We'll eventually introduce you to a tool that can help give you more information for debugging these errors.

At the very least you now know that if you get a segmentation fault, you should be suspicious of your array indices!

Here's a slightly different snippet:

int x = 444;
int a[3]{1, 2, 3};
int y = 555;
cout << a[1000000000] << endl;

Summary

• Accessing an array out of bounds is “undefined behavior”.
  • Literally no outcome are ruled out, as far as the C++ standard is concerned.
  • You should never write a program that relies on a particular outcome when the behavior is undefined.
• Typical C++ compilers produce code that does things the fastest and easiest way, without any special safety checks while the program is running.
  • Thus we shouldn't be surprised if the program finds the place in memory where the item would have been if the array had been that big, and interprets whatever bits happen to be there as the type it's expecting.
  • Accessing an array out of bounds can cause strange behavior because the compiler assumes that you're following the rules.
• On our systems, accessing memory that is way out of bounds can cause your program to crash.
  • A modern operating system will not allow your program to access memory outside of its allotted region.
  • This error is called a “segmentation fault” (“segfault” for short).

(When logged in, completion status appears here.)