Re: Avoiding _memset?
"Vincent Fatica" wrote:
If you look at the CRT startup routines (the typical entry
points, crtexe.c) for EXEs, you see that they are __cdecl,
taking, no args and returning an int. They examine a command
line, do their thing, and eventually call main, wmain, or
WinMain. So the signatures of main, wmain, and WinMain are very
important. But if you're not using the CRT startup routines and
you are specifying an entry point, it would seem that int
__cdecl ...(void) is appropriate.
I found the requirements here:
"/ENTRY (Entry-Point Symbol)"
http://msdn.microsoft.com/en-us/library/f9t8842e.aspx
<quote>
The function must be defined with the __stdcall calling
convention. The parameters and return value must be defined as
documented in the Win32 API for WinMain (for an .exe file) or
DllEntryPoint (for a DLL).
</quote>
However, after reading your answer I looked into crtexe.c file I
discovered that CRT startup routines don't respect this
requirement, exactly as you noticed. Moreover, BaseProcessStart
routine from kernel32.dll doesn't care neither about parameters
nor calling convention. The call looks like this:
call dword ptr [ebp+8]
push eax
call _ExitThread@4
Where "dword ptr [ebp+8]" is the address of the process entry
point. The process entry point address is passed as a parameter to
BaseProcessStart, as well.
So, actually the linker documentation is incorrect and one must
use int __cdecl(*)(void) function as a custom entry point. It is
only by sheer luck BaseProcessStart and subsequent code don't
change anything on stack, so there is no access violation
exception.
I would be very interested in hearing from MSFT people about the
issue.
Alex