In C language, why does function parameters go from right to left into the stack?

In C language, why does function parameters go from right to left into the stack?

Let's take a look at it through a small program:

#includevoid foo(int x, int y, int z){printf(x = %d at [%X]n, x, &x);printf(y = %d at [%X]n, y, &y);printf(z = %d at [%X]n, z, &z);}int main(int argc, char *argv[]){foo(100, 200, 300);return 0;}

Running result:
X = 100 at [BFE28760]
Y = 200 at [BFE28764]
Z = 300 at [BFE28768]

The C program stack bottom is a high address, and the stack top is a low address. Therefore, the above instance can indicate that the function parameter's import sequence to the stack is indeed from right to left. But why? According to the literature, the parameter stack order is related to the specific compiler implementation. For example, in Pascal, parameters are written from left to right into the stack, and some languages can also be specified through modifiers, such as Visual C ++. either method works. Why does the C language need to be right-to-left?

We further found that Pascal does not supportVariable Length parameters, which are supported by C language, make the order of C function parameters in the stack from right to left.The specific cause is that the number of parameters can be dynamically changed because of the advantage of the C-mode parameter entry sequence (from right to left. Stack heap analysis shows that the top parameters of the stack are pressed at the bottom of the stack from left to right. Unless you know the number of parameters, you cannot obtain the leftmost parameter through the relative displacement of the stack pointer. This makes the number of parameters on the left uncertain, which is the opposite of the number of dynamic parameters.

Therefore, C language function parameters adopt the order of inbound Stack from right to left, mainly because they support variable length parameters. In other words, if this feature is not supported, the C language is exactly the same as Pascal and uses the parameter stack mode from left to right.

The method used in the C language call Convention is also involved here. The following is a brief introduction:

Differences between _ stdcall and C call conventions (_ cdecl)

The C call Convention requires a stack balance before the return, that is, the number of bytes that the parameter has written into the stack should pop up. This is safe.

Note that if the variable parameter VARARG is used in the stdcall call convention, the caller must balance the stack like the C call convention.

(1) _ stdcall is a method used by Pascal to clear C-mode pressure stacks. Generally, it is used in Win32 APIs. functions use the stack pressure mode from right to left to clear stacks when they exit. After compiling a function, VC adds an underline prefix to the function name, and adds "@" and the number of bytes of the parameter to the function name. Int f (void * p)-> _ f @ 4 (this function can be referenced in an external assembly language)

In WIN32 APIs, there are only a few functions. For example, wspintf uses the C call convention, and all others use stdcall.

(2) C call conventions (The C default calling convention is described by The _ cdecl keyword) are pushed to The stack in The order from right to left, the caller pushes the parameter to the stack. The memory stack of the transfer parameter is maintained by the caller (because of this, the variable parameter vararg function (such as printf) can only use this call Convention ). In addition, the function name modification conventions are also different. _ Cdecl is the default call Method for C and C ++ programs. Every function that calls it contains the code to clear the stack. Therefore, the size of the executable file generated is larger than that of the call to the _ stdcall function. The function uses the stack pressure mode from right to left. After compiling a function, VC adds an underline prefix to the function name.

(3) _ fastcall is fast because it transmits parameters through registers (in fact, it uses ECX and EDX to transmit the first two Dwords) for smaller parameters, the remaining parameters are still transmitted from the right to the left pressure stack, And the called function clears the memory stack of the transferred parameter before returning). In terms of function name modification conventions, it is different from the previous two. _ Fastcall functions use registers to pass parameters. After compiling a function, VC adds the "@" prefix to the function name, add "@" after the function name and the number of bytes of the parameter.

(4) thiscall is only applied to the "C ++" member function. This pointer is stored in the CX/ECX register, and the parameter is pressed from right to left. Thiscall is not a keyword and cannot be specified by programmers.

(5) naked call. When 1-4 calls are adopted, the compiler will generate code to save ESI, EDI, EBX, and EBP registers when entering the function if necessary, when you exit the function, the code is generated to restore the content of these registers.

(These codes are called prolog and epilog code. Generally, the storage of ebp and esp is required ).

However, naked call does not generate such code. The naked call is not a type modifier, so it must be used together with _ declspec.

The keywords _ stdcall, _ cdecl, and _ fastcall can be directly added before the function to be output. Their corresponding command line parameters are/Gz,/Gd, And/Gr. The default status is/Gd, Which is _ cdecl.

To fully imitate PASCAL's call convention, you must first use the _ stdcall call Convention. As for the function name Modification Convention, you can use other methods to imitate it. Another thing worth mentioning is WINAPI macro, Windows. h supports this macro. It can translate the function into an appropriate call convention. In WIN32, it is defined as _ stdcall. You can use the WINAPI macro to create your own APIs.

In summary, only PASCAL calls the stack from left to right, and PASCAL cannot use an indefinite number of parameters. The number of parameters is certain.

Briefly summarize the preceding call methods: