Exceeding array bound in C -- Why does this NOT crash?

Question

I have this piece of code, and it runs perfectly fine, and I don't why:

int main(){
   int len = 10;
   char arr[len];
   arr[150] = 'x';
}

Seriously, try it! It works (at least on my machine)! It doesn't, however, work if I try to change elements at indices that are too large, for instance index 20,000. So the compiler apparently isn't smart enough to just ignore that one line.

So how is this possible?

Answer: I can use this to write into memory consumed by other variables on the stack, like so:

#include <stdio.h>
main(){
   char b[4] = "man";
   char a[10];
   a[10] = 'c';
   puts(b);
}

Outputs "can". That's a really bad thing to do.

It's not running fine though, it is invoking undefined behavior. You are writing into memory that you shouldn't be. The effects are unpredictable. — Brian Neal, Mar 07 '13 at 01:37
I *know* this exact question has been asked, particularly from a Java background. This is very well phrased; wish there were an easy way to bookmark this to mark others as a duplicate. — Potatoswatter, Mar 07 '13 at 01:47
possible duplicate of [C Array Bounds error with adjacent object](http://stackoverflow.com/questions/9151624/c-array-bounds-error-with-adjacent-object) — Jay Gilford, Mar 07 '13 at 01:51
possible duplicate of [C++ Accesses an Array out of bounds gives no error, why?](http://stackoverflow.com/questions/1239938/c-accesses-an-array-out-of-bounds-gives-no-error-why) — jogojapan, Mar 07 '13 at 01:52
@s0rce: No automatic bounds checking is guaranteed by the C standard. However, the standard leaves room for conforming implementations to perform automatic bounds checking. — Dietrich Epp, Mar 07 '13 at 02:18
possible duplicate of [How dangerous is it to access an array out of bounds?](http://stackoverflow.com/questions/15646973/how-dangerous-is-it-to-access-an-array-out-of-bounds) — Jonathan Leffler, Apr 18 '13 at 01:05
Possible duplicate of [Array index out of bound in C](http://stackoverflow.com/questions/671703/array-index-out-of-bound-in-c) — phuclv, Aug 04 '16 at 06:36

score 6 · Answer 1 · answered Mar 07 '13 at 01:34

C compilers generally do not generate code to check array bounds, for the sake of efficiency. Out-of-bounds array accesses result in "undefined behavior", and one possible outcome is that "it works". It's not guaranteed to cause a crash or other diagnostic, but if you're on an operating system with virtual memory support, and your array index points to a virtual memory location that hasn't yet been mapped to physical memory, your program is more likely to crash.

score 4 · Answer 2 · answered Mar 07 '13 at 01:39

So how is this possible?

Because the stack was, on your machine, large enough that there happened to be a memory location on the stack at the location to which &arr[150] happened to correspond, and because your small example program exited before anything else referred to that location and perhaps crashed because you'd overwritten it.

The compiler you're using doesn't check for attempts to go past the end of the array (the C99 spec says that the result of arr[150], in your sample program, would be "undefined", so it could fail to compile it, but most C compilers don't).

Dietrich Epp · Answer 3 · 2013-03-07T02:12:20.557

Most implementations don't check for these kinds of errors. Memory access granularity is often very large (4 KiB boundaries), and the cost of finer-grained access control means that it is not enabled by default. There are two common ways for errors to cause crashes on modern OSs: either you read or write data from an unmapped page (instant segfault), or you overwrite data that leads to a crash somewhere else. If you're unlucky, then a buffer overrun won't crash (that's right, unlucky) and you won't be able to diagnose it easily.

You can turn instrumentation on, however. When using GCC, compile with Mudflap enabled.

$ gcc -fmudflap -Wall -Wextra test999.c -lmudflap
test999.c: In function ‘main’:
test999.c:3:9: warning: variable ‘arr’ set but not used [-Wunused-but-set-variable]
test999.c:5:1: warning: control reaches end of non-void function [-Wreturn-type]

Here's what happens when you run it:

$ ./a.out 
*******
mudflap violation 1 (check/write): time=1362621592.763935 ptr=0x91f910 size=151
pc=0x7f43f08ae6a1 location=`test999.c:4:13 (main)'
      /usr/lib/x86_64-linux-gnu/libmudflap.so.0(__mf_check+0x41) [0x7f43f08ae6a1]
      ./a.out(main+0xa6) [0x400a82]
      /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd) [0x7f43f0538ead]
Nearby object 1: checked region begins 0B into and ends 141B after
mudflap object 0x91f960: name=`alloca region'
bounds=[0x91f910,0x91f919] size=10 area=heap check=0r/3w liveness=3
alloc time=1362621592.763807 pc=0x7f43f08adda1
      /usr/lib/x86_64-linux-gnu/libmudflap.so.0(__mf_register+0x41) [0x7f43f08adda1]
      /usr/lib/x86_64-linux-gnu/libmudflap.so.0(__mf_wrap_alloca_indirect+0x1a4) [0x7f43f08afa54]
      ./a.out(main+0x45) [0x400a21]
      /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd) [0x7f43f0538ead]
number of nearby objects: 1

Oh look, it crashed.

Note that Mudflap is not perfect, it won't catch all of your errors.

By what i have learnt in OS , is that any process accessing any memory[allocated by VM to its pid or not] , will cause a page fault exception , and then the vm , will check the permission for that page , and based on that will allocate it [Demand paging] , or will give a segmentation fault , so your answer implies that , it all depends on the granularity of pages ?? Am sure you are right , but can i read more about this anywhere online ?? — Barath Ravikumar, Mar 07 '13 at 12:20
@BarathBushan: This will be covered in almost any book on OS theory. You can also look through [Apple's documentation](https://developer.apple.com/library/mac/#documentation/performance/conceptual/managingmemory/articles/aboutmemory.html), which says that "In both OS X and iOS, the size of a page is 4 kilobytes." — Dietrich Epp, Mar 07 '13 at 19:57

Potatoswatter · Answer 4 · 2013-03-07T02:29:44.953

Native C arrays do not get bounds checking. That would require additional instructions and data structures. C is designed for efficiency and leanness, so it doesn't specify features that trade performance for safety.

You can use a tool like valgrind, which runs your program in a kind of emulator and attempts to detect such things as buffer overflows by tracking which bytes are initialized and which aren't. But it's not infallible, for example if the overflowing access happens to perform an otherwise-legal access to another variable.

Under the hood, array indexing is just pointer arithmetic. When you say arr[ 150 ], you are just adding 150 times the sizeof one element and adding that to the address of arr to obtain the address of a particular object. That address is just a number, and it might be nonsense, invalid, or itself an arithmetic overflow. Some of these conditions result in the hardware generating a crash, when it can't find memory to access or detects virus-like activity, but none result in software-generated exceptions because there is no room for a software hook. If you want a safe array, you'll need to build functions around the principle of addition.

By the way, the array in your example isn't even technically of fixed size.

int len = 10; /* variable of type int */
char arr[len]; /* variable-length array */

Using a non-const object to set the array size is a new feature since C99. You could just as well have len be a function parameter, user input, etc. This would be better for compile-time analysis:

const int len = 10; /* constant of type int */
char arr[len]; /* constant-length array */

For the sake of completeness: The C standard doesn't specify bounds checking but neither is it prohibited. It falls under the category of undefined behavior, or errors that need not generate error messages, and can have any effect. It is possible to implement safe arrays, various approximations of the feature exist. C does nod in this direction by making it illegal, for example, to take the difference between two arrays in order to find the correct out-of-bounds index to access an arbitrary object A from array B. But the language is very free-form, and if A and B are part of the same memory block from malloc it is legal. In other words, the more C-specific memory tricks you use, the harder automatic verification becomes even with C-oriented tools.

score 0 · Answer 5 · answered Mar 07 '13 at 01:42

Under the C spec, accessing an element past the end of an array is undefined behaviour. Undefined behaviour means that the specification does not say what would happen -- therefore, anything could happen, in theory. The program might crash, or it might not, or it might crash hours later in a completely unrelated function, or it might wipe your harddrive (if you got unlucky and poked just the right bits into the right place).

Undefined behaviour is not easily predictable, and it should absolutely never be relied upon. Just because something appears to work does not make it right, if it invokes undefined behaviour.

score 0 · Answer 6 · answered Mar 07 '13 at 01:42

0

Because you were lucky. Or rather unlucky, because it means it's harder to find the bug.

The runtime will only crash if you start using the memory of another process (or in some cases unallocated memory). Your application is given a certain amount of memory when it opens, which in this case is enough, and you can mess about in your own memory as much as you like, but you'll give yourself a nightmare of a debugging job.

answered Mar 07 '13 at 01:42

Dave

44,275
12
65
105

Under modern OSes, protected virtual memory means there's no chance to access another process's memory without explicitly mapping it (via shared memory or some other mechanism). Every process has its own memory space. Accessing *unmapped* memory, or writing to *read-only* memory, or performing *unaligned accesses* (on some platforms) are ways in which you could crash a process. – nneonneo Mar 07 '13 at 01:43
It's also worth noting that this is the operating system (and these days often the processor itself). The language and compiler have nothing to do with it. Very old systems wouldn't stop you doing this, and were all the more hackable for it. – Dave Mar 07 '13 at 01:45

Exceeding array bound in C -- Why does this NOT crash?

6 Answers6

Linked

Related