Writing to a pointer outside the bounds after malloc (), which does not cause errors

Question

when i try to use the code below it works fine. Did I miss something?

main() { int *p; p=malloc(sizeof(int)); printf("size of p=%d\n",sizeof(p)); p[500]=999999; printf("p[0]=%d",p[500]); return 0; } 

I tried it with malloc (0 * sizeof (int)) or something else, but it works fine. The program only crashes when I do not use malloc at all. Therefore, even if I allocate 0 memory for the p array, it still saves the values ​​correctly. So why am I even worried about malloc?

Answer 1

It may work fine, but it is not very safe. By writing data outside the allocated memory block, you are overwriting some data that should not be. This is one of the biggest causes of segfaults and other memory errors, and what you observe with it working in this short program makes it difficult to find the root cause.

Read this article , in particular the memory corruption part, to begin to understand the problem.

Valgrind is a great tool for analyzing memory errors, such as the one you provide.

@ David made a good comment. Compare the results of your code execution with the following code , Note that the latter leads to a runtime error (with practically no useful output!) On ideone.com (click on the links), while the former succeeds as you survived.

 main() { int *p; p=malloc(sizeof(int)); printf("size of p=%d\n",sizeof(p)); p[500]=999999; printf("p[0]=%d",p[500]); p[500000]=42; printf("p[0]=%d",p[500000]); return 0; } 

Answer 2

If you do not allocate memory, p has garbage in it, so writing to it will most likely fail. After you make a valid call to malloc, p points to a valid memory location, and you can write to it. You are rewriting a memory that should not be written, but no one is going to hold your hand and talk about it. If you run your program and a memory debugger like valgrind, this will tell you. Welcome to C.

Answer 3

Writing the end of your memory is Undefined Behavior ™, which means that something can happen, including your program, as if you had just made it completely legal. The reason your program works as if you were executing malloc(501*sizeof(int)) was completely implementation specific and could indeed be specific to everything, including the moon phase.

Answer 4

This is because P will be assigned some kind of address no matter what size you use with malloc (). Although with zero size you are referring to invalid memory, since the memory was not allocated, but it may be in a place that will not cause the program to crash, although the behavior will be undefined.

Now, if you do not use malloc (), it will point to the garbage location and try to gain access, which may lead to a program crash.

Answer 5

I tried it with malloc (0 * sizeof (int))

According to C99, if the size passed to malloc is 0, the C runtime can either return a NULL pointer or the distribution behaves as if the request were for a non-zero distribution, except that the returned pointer should not be dereferenced, So this implementation is defined (for example, some implementations return a zero-length buffer), and in your case you are not returning a NULL pointer, but you are using a pointer that you should not use. If you try it in a different runtime, it may return a NULL pointer.

Answer 6

When you call malloc (), a small piece of memory is cut out from a larger page for you.

  malloc(sizeof(int)); 

Actually does not allocate 4 bytes on a 32-bit machine (the allocator imposes it on the minimum size) + heap metadata size used to track the piece over its life (pieces are placed in bunkers based on their size and marked in use or free from the allocator). hxxp: //en.wikipedia.org/wiki/Malloc or, more specifically, hxxp: //en.wikipedia.org/wiki/Malloc#dlmalloc_and_its_derivatives if you are testing this on Linux.

Thus, writing beyond your chunk does not necessarily mean that you are about to break. At p + 5000, you don’t write outside the page allocated for this initial fragment, so you technically record the actual mapped address. Welcome to memory corruption. http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=heap+overflows

Answer 7

Our CheckPointer tool may detect this error. He knows that the distribution of p was up to 4 bytes, and thus the assignment has been completed, it is outside the scope for which p was allocated. He will tell you that the assignment p [500] is wrong.