Simple Analysis of function calling process in C Language

# Include <stdio. h> 2 3 void input () 4 {5 int I; 6 int array [20]; 7 for (I = 0; I <20; I ++) 8 {9 array [I] = I; 10} 11} 12 13 void output () 14 {15 int I; 16 int array [20]; 17 for (I = 0; I <20; I ++) 18 {19 printf ("% d \ n", array [I]); 20} 21} 22 23 int main () 24 {25 input (); 26 output (); 27 while (1) {} 28 return 0; 29} The purpose of copying the code is very simple, the input function defines array [20] and assigns values. It is output in the output function. The running result is as follows: Nice Work! But ...... What about printf () after input ????? Copy code 1 int main () 2 {3 input (); 4 printf ("any string"); 5 output (); 6 while (1) {} 7 return 0; 8} copy the code. As long as you have been studying C language for a while, you will find that the array [20] defined in those two functions has a problem, the two arrays have nothing to do with each other. If such code is used, the first response is to associate the two arrays through the parameter or global variable method. But, the problem ...... Wang Nima is a newbie. He defines the two arrays as the same name and thinks they are the same array. In addition, he said, "my previous code is okay, A problem occurs when only a printf is added. It should be the problem here. How can it be the problem of defining an array? Nima, this is just a coincidence. Your first program is wrong! But my output is correct ...... As we all know, the root cause of the problem is that although the array in the output and input functions has the same name, it is not the same array, but it just happens to output the previously assigned memory, to explain this problem, you need to understand how the C language changes the stack during function calling. First of all, it is also very important to make it clear that the stack grows down. The so-called downward growth refers to the extension from the memory high address> low address path, so it is very obvious, the stack has a stack bottom and a stack top, so the stack top address is lower than the stack bottom. For the CPU Of The x86 system, the ---> Register ebp (base pointer) can be called "frame pointer" or "base address pointer". In fact, the meaning is the same. ---> Register esp (stack pointer) can be called a "stack pointer ". You need to know: ---> before being changed, ebp always points to the beginning of the stack frame, that is, the bottom of the stack. Therefore, ebp is used for addressing in the stack. ---> Esp moves along with the data's inbound and outbound stacks. That is to say, esp always points to the top of the stack. See, if function A calls function B, we call function A as "Caller", and function B as "called", the function call process can be described as follows: (1) first, the caller (A)'s stack base address (ebp) is added to the stack to save the previous Task information. (2) then, the value of the caller (A) stack top pointer (esp) is assigned to ebp as the new base address (that is, the bottom of the stack of the caller B ). (3) then, the corresponding space (generally using sub commands) is opened on the base address (the bottom of the stack of caller B) for the stack space of consumer B. (4) After function B returns, the ebp of the current stack frame is restored to the top stack (esp) of caller A, so that the top of the stack is restored to the position before function B is called; then caller A can pop up the previous ebp value from the restored stack top (this can be done because the value is pushed into the stack one step before the function call ). In this way, both ebp and esp restore the position before function B is called, that is, the stack restores the status before function B is called. Back to the previous problem, because the input and output functions allocate the same address to the space of their array, the content can be output smoothly. However, after the printf function is called, because part of the stack is modified, the first half of the output result is correct, and the second half is incorrect. Here, I believe some kids shoes will try to run this code. If you use Turbo C, congratulations! You can get the same results (the above results are tested in Turbo C); if you use Visual Studio XXXX, the following result is displayed: what is the problem? After checking the disassembly, we found that in the Debug version, for convenience of debugging, VS will initialize the array to 0 xCCCCCCCC, And the array in the output function is just defined, therefore, when the VS initialization bit is 0 xCCCCCCCC, the conversion to unsigned int Is-858993460. Of course, in the Release version, the default initialization operation is not performed on the array to improve efficiency. What is the result? Nana ?! If VS does not initialize the array, the result is Mao and Turbo C ...... In this case, we can only use disassembly again. See. It can be found that the input function does not have the corresponding Assembly statement. That is to say, the compiler has optimized the input function because it does nothing. Since the array is not assigned a value, the output is naturally a mess of data in the memory. As for what GCC will get, as a Windows party, it will not be tested. If you are interested, you can adjust the compilation options and try it yourself.