First take a look at the following C program fragment:
＃i nclude <malloc.h>
char *p;
p = (char * ) malloc (10);
p = (char * ) realloc (p,20);
…………………………
The meaning of this program is very simple, and anyone with a little bit of C knowledge can understand it. The function first defines a character pointer p, then allocates a 10-byte memory space for the pointer p, and then increases the size of this memory block to 20 bytes.
Is there something wrong here? Run it on the computer, it seems there is no problem!
Yes, there is no problem in running it on the computer like this, but there are hidden dangers that we may not pay much attention to! Where are the hidden dangers? This is the realloc() function that I will explain in detail in this article.
Take another look at the following passage from MSDN:
realloc returns a void pointer to the reallocated (and possibly moved) memory block. The return value is NULL if the size is zero and the buffer argument is not NULL, or if there is not enough available memory to expand the block to the given size. In the first case, the original block is freed. In the second, the original block is unchanged. The return value points to a storage space that is guaranteed to be suitably aligned for storage of any type of object. To get a pointer to a type other than void, use a type cast on the return value.
This E article is not too obscure, so I won’t translate it. The general meaning is about the return value of realloc. But here are several situations for its return value:
1. Return void * pointer and the call is successful.
2. Return NULL. When the size to be expanded (the second parameter) is 0 and the first parameter is not NULL, the original memory becomes "freed".
3. Return NULL. When there is not enough space for expansion, the size of the original memory space remains unchanged.
The first situation tells us that we need to do type conversion after getting the required memory space;
In the second case, only fools would use it!
In the third case, when the memory space is insufficient, the future size will remain unchanged.
MSDN says that when the memory space is insufficient, the original memory space will not be expanded. This is certainly true, but it is a bit vague and seems to have missed a situation! We know that realloc allocates memory from the heap. When expanding a memory space, realloc() tries to obtain additional bytes directly from the bytes behind the existing data on the heap. If it can be satisfied, the world will naturally be peaceful; But if there are not enough bytes behind the data, a problem arises. Then the first free block of sufficient size on the heap is used. The existing data is then copied to the new location, and the old block is put back on the heap. superior. An important message conveyed by this sentence is that data may be moved! Seeing this, maybe we have discovered the problem with the program I gave at the beginning. In order to explain the problem more clearly, the above program can be changed into the following form:
＃i nclude <malloc.h>
char *p，*q;
p = (char * ) malloc (10);
q=p;
p = (char * ) realloc (p,20);
…………………………
This program may not pass in the compiler, because the compiler may eliminate some hidden dangers for us! Here we just add a pointer q that records the original memory address, and then record the original memory address p. If unfortunately, the data moves, then the memory space pointed to by the recorded original memory address q has actually been Put it back on the pile! In this way, we should finally realize what the problem is and how terrible it is!
This problem seems to be a bit over the top, because we may have never encountered it, but we should understand that such things always exist. Only in this way can we consciously avoid such hidden dangers if we encounter them. Otherwise, once such a hidden danger occurs and the program crashes, it may not be easy to find the error!
Hou Junjie quoted a sentence from Lin Yutang's "The Great Family" in "MFC". I was very moved. Although it is impossible to have as deep a feeling as him, I have the mentality of learning from the predecessors, so I also use it as my original guide. Finish:
This article comes from the CSDN blog. Please indicate the source when reprinting: http://blog.csdn.net/sshcx/archive/2006/11/14/1384039.aspx