What happens if I set a value outside of the memory allocated with calloc?

Question

Consider the following:

int* x = calloc(3,sizeof(int));
x[3] = 100;

which is located inside of a function.

I get no error when I compile and run the program, but when I run it with valgrind I get an "Invalid write of size 4".

I understand that I am accessing a memory place outside of what I have allocated with calloc, but I'm trying to understand what actually happens.

Does some address in the stack(?) still have the value 100? Because there must certainly be more available memory than what I have allocated with calloc. Is the valgrind error more of a "Hey, you probably did not mean to do that"?

Answer 1

I understand that I am accessing a memory place outside of what I have allocated with calloc, but I'm trying to understand what actually happens.

"What actually happens" is not well-defined; it depends entirely on what gets overwritten. As long as you don't overwrite anything important, your code will appear to run as expected.

You could wind up corrupting other data that was allocated dynamically. You could wind up corrupting some bit of heap bookkeeping.

The language does not enforce any kind of bounds-checking on array accesses, so if you read or write past the end of the array, there are no guarantees on what will happen.

Answer 2

Does some address in the stack(?) still have the value 100?

First of all, calloc allocates memory on the heap not stack.

Now, regarding the error.

Sure most of the time there is plenty of memory available when your program is running. However when you allocate memory for x bytes, the memory manager looks for some free chunk of memory of that exact size(+ maybe some more if calloc requested larger memory to store some auxiliary info), there are no guaranties on what the bytes after that chunk are used for, and even no guaranties that they are not read-only or can be accessed by your program.

So anything can happen. In the case if the memory was just there waiting for it to be used by your program, nothing horrible happens, but if that memory was used by something else in your program, the values would be mess up, or worst of all the program could crash because of accessing something that wasn't supposed to be accessed.

So the valgrind error should be treated very seriously.

The C language doesn't require bounds checking on array accesses, and most C compilers don't implement it. Besides if you used some variable size instead of constant value 3, the array size could be unknown during compilation, and there would be no way to check if the access isn't out of bound.

Answer 3

There's no guarantees on what was allocated in the space past x[3] or what will be written there in the future. alinsoar mentioned that x[3] itself does not cause undefined behavior, but you should not attempt to fetch or store a value from there. Often you will probably be able to write and access this memory location without problems, but writing code that relies on reaching outside of your allocated arrays is setting yourself up for very hard to find errors in the future.

Does some address in the stack(?) still have the value 100?

When using calloc or malloc, the values of the array are not actually on the stack. These calls are used for dynamic memory allocation, meaning they are allocated in a seperate area of memory known as the "Heap". This allows you to access these arrays from different parts of the stack as long as you have a pointer to them. If the array were on the stack, writing past the bounds would risk overwriting other information contained in your function (like in the worst case the return location).

Answer 4

The act of doing that is what is called undefined behavior. Literally anything can happen, or nothing at all.

I give you extra points for testing with Valgrind.

In practice, it is likely you will find the value 100 in the memory space after your array.

Beware of nasal demons.

Answer 5

You're allocating memory for 3 integer elements but accessing the 4th element (x[3]). Hence, the warning message from valgrind. Compiler will not complain about it.