Call specification and variable parameter table

The language invocation specification refers to the method of passing parameters used in a function call, the processing of the return value, and the cleanup of the call stack. There are five invocation specifications in the Microsoft C + + language, respectively, __cdecl, __stdcall, __fastcall,thiscall, and Nake each of the calling specifications use EAX as the return value, and if the function return value is 64-bit, The edx:eax pair is used to return the value. The Nake call specification is very flexible enough to be independent of an article description where the Nake invocation specification is no longer described. The following table lists the characteristics of the previous four specification calls:

Key words	Stack cleanup person	Parameter Pass Order
__cdecl	By the caller	From right to left
__stdcall	Called by	From right to left
__fastcall	Called by	From right to left, the first two parameters are passed by register Ecx,edx
ThisCall	Callee or caller	From right to left

The biggest advantage of __cdecl is that because it is the caller cleanup stack, it can handle variable parameters, but the disadvantage is that it increases the size of the program, because when each call returns, you need to execute a stack of instructions more.

__stdcall is the most common calling rule that occurs in Windows programming, and is used by all API calls to immutable parameters.

__fastcall is widely used in Windows kernel design, because two parameters are transmitted directly from registers, the function efficiency of this rule is higher than the above two kinds of rules.

ThisCall is the default invocation specification for C + + member functions, which, during compilation, determines how the stack is cleaned up based on whether the function supports a variable parameter table. If a member function does not support a variable parameter, it is called with the parameter in the stack, ECX save the This pointer, and if the member function supports variable parameters, then its invocation is similar to __cdecl, except that the this pointer is finally pushed into the stack for delivery.

The caller and the callee must adopt the same rules to guarantee the normal execution of the program, and the errors that many programmers have made are the result of different calling specifications, resulting in program abnormalities, such as:

DWORD ThreadFunc(LPVOID lpParam)
{
//…
}
CreateThread(..,(LPTHREAD_START_ROUTINE)ThreadFunc, …);

If the compilation option/GZ is not specified during compilation (specifying that a function that does not indicate the calling specification is __stdcall), the compiler automatically processes the ThreadFunc into the __cdecl invocation specification (/GD), which may normally execute at the start of the thread. However, when exiting because the stack did not clean up properly, resulting in access violations or illegal instruction errors.

The above mentioned a lot of cleaning up the stack of problems, then why the clean-up stack is important. The stack is thread-related, that is, each thread contains a stack, which holds local variables, invokes data related to many threads such as the return address, which is why a thread that runs independently can invoke the same function without interfering. The characteristics of the stack I'm afraid everyone is very familiar with it, so based on each of these calls, I give a simple illustration of the importance of cleaning up the stack and why the above example code is wrong.

Figure one this is what the thread stack looks like when it's running