Why does this not produce a segmentation fault

Question

This is a for loop in c++. I dont understand why it does not give a segmentation fault on execution.

int main() 
{
   int arr[5];
   for (int x = 0; x <= 5; x++)
       {
           arr[x] = x;
       }
   return 0; 
}

This is coming from someone who codes in Java, Javascript and C#... Why should that result in an error? — Geeky Guy, May 07 '13 at 20:46
@Renan The array has 5 elements with indices 0 to 4. Index 5 is being accessed. — Joseph Mansfield, May 07 '13 at 20:47
@sftrabbit Thanks. I expected that in C++ that would just cause the program to try and read the next 4 (or 2 or 8 in some machines) bytes in memory, right next to those allocated for the 5th position. But then again, C++ is not my forte. — Geeky Guy, May 07 '13 at 20:49
@Renan Well yes, probably. That's why it's undefined behaviour. — Joseph Mansfield, May 07 '13 at 20:52

Andy Prowl · Accepted Answer · 2013-05-07T21:06:35.850

18

This is undefined behavior. Undefined behavior means that anything can happen, including:

segmentation fault
no error at all
inconsistent output
formatting of hard drive
... (whatever)

To get a bit more formal, this is how the C++11 Standard defines undefined behavior:

behavior for which this International Standard imposes no requirements [ Note: Undefined behavior may be expected when this International Standard omits any explicit definition of behavior or when a program uses an erroneous construct or erroneous data. Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message). Many erroneous program constructs do not engender undefined behavior; they are required to be diagnosed. —end note ]

Concerning the reason why doing x[5] is indeed undefined behavior, that's because x[5] is equivalent to *(x + 5) (see paragraph 8.3.4/6), and paragraph 5.3.1/1 about the unary operator * specifies:

The unary * operator performs indirection: the expression to which it is applied shall be a pointer to an object type, or a pointer to a function type and the result is an lvalue referring to the object or function to which the expression points. If the type of the expression is “pointer to T,” the type of the result is “T.” [...]

But since x + 5 does not point to any object, and the above paragraph does not specify what the result of dereferencing such a pointer should be, the previously quoted sentence applies:

[...] Undefined behavior may be expected when this International Standard omits any explicit definition of behavior [...]

Which means that x[5] is undefined behavior.

edited May 07 '13 at 21:06

answered May 07 '13 at 20:45

Andy Prowl

124,023
23
387
451

1

Why is it undefined behaviour? – someguy May 07 '13 at 20:47
2

@someguy, Because it allows the compiler to perform certain optimizations. – chris May 07 '13 at 20:48
@someguy To allow for certain optimizations that assume you write well defined code. – Joseph Mansfield May 07 '13 at 20:48
1

Trying to set the value of `arr[5]` is the undefined part, correct? – John May 07 '13 at 20:48
formatting hard drive. seriously? – psibar May 07 '13 at 20:48
1

@psibar: Very unlikely; ) But from the formal viewpoint, yes – Andy Prowl May 07 '13 at 20:49
@psibar, If the compiler wants to, sure. It's more of a joke than an expected result, but it's not impossible on a conforming compiler. – chris May 07 '13 at 20:49
4

There needs to be a C++ compiler that detects undefined behaviour when it can and actually formats the hard drive. Dangerous coding. – Joseph Mansfield May 07 '13 at 20:50
@sftrabbit: The result would definitely be worth the pain of forking GCC. :D – syam May 07 '13 at 20:52
@AndyProwl Thanks, but I'm obviously missing something. That's in essence what the other answers have (including mine) but they're getting slammed. What did I miss in my answer? – John May 07 '13 at 20:53
@AndyProwl Never mind. I see now. – John May 07 '13 at 20:53
The answers that got slammed totally misread the question. – drescherjm May 07 '13 at 20:55

score 3 · Answer 2 · answered May 07 '13 at 20:51

A segmentation fault occurs when a user program attempts to do one of :

Access a part of the memory it is not allowed to, such as system memory
Access a part of the memory which does not exist (aka out of bounds)

So you are correct in realizing that you are reaching out of bounds in your array, and on the last loop iteration you are accessing something outside of your program's allocated memory. It just so happens that the piece of memory is not system memory and it exists, so it lets you read it.

If you ran this bit of code enough times you should eventually get a segmentation fault because it will happen to be placed right up against system memory or at the end of memory.

I question the last part. On systems with virtual memory that I know of it does not work that way. Each program gets its own address space and does not interfere with other applications address spaces except for shared memory. — drescherjm, May 07 '13 at 21:03

score 1 · Answer 3 · answered May 07 '13 at 20:53

I think Andy Prowl has already answered best in saying that it's undefined behaviour.

But if you're interested in the specifics of why it doesn't crash, on my compiler at least, the variable x is allocated in the position on the stack immediately following the array. When you assign x to arr[5], you're really just assigning x back to itself.

Obviously this may be different from one compiler to the next. Just thought you might be interested to know at least what one particular compiler is doing.

Why does this not produce a segmentation fault

3 Answers3

Linked