I'm looking at the asm code generated by a VC compiler. I'm curious to see how ebp reg is used.

The source code is written in C language. What I'm looking is

int myFunc (par1, par2, par3) {
int iLoc ;
if (par1 == 1) iLoc = 16 ;
else iLoc = 1 ;

par2 = 0 ;

par3 = par3 * 2 ;

return 1 ;

When my function is called I see that a large stack area is reserved for local variables. In my case the only local variable - which is an int so 4 bytes long - would need 4 bytes. Instead the compiler reserved an area of 44h bytes and moreover filled with 0CCCCCCCCh values.

The asm code is

push ebp
mov ebp,esp
sub esp,44h ; an area of 17 DWORDs !!!
push ebx
push esi
push edi
lea edi,
mov ecx,11h
mov eax,0CCCCCCCCh
rep stos dword ptr ; the area is filled with 'C'... is it because source code was written in 'C'??? ;-P

Posted on 2004-04-15 08:53:03 by _OuzO_
I presume it is because you build your program in debug mode and CC should be a kind of protection in casa an error occurs ;) . It is unlikely that the C compiler you are using is so much unoptimised...
Posted on 2004-04-15 13:14:00 by BogdanOntanu
You are probably using one of the more recent .net versions of visual studio. Have a look at project properties -> C/C++ -> Code Generation. For release builds, turn off "Buffer security checks", "Function-level linking", "basic runtime checks", "smaller type checks".
Posted on 2004-04-15 13:33:15 by f0dder
it will initilize stack values with the value of 0xCCCCCCCC in debug. so compile as release and it should'nt do that. i guess it does that so if theres a buffer overflow/run etc it will exec opcode CCh which is int 13 and break execution. at least thats my explanation of why they have it do that.
Posted on 2004-04-16 00:45:55 by Qages

... it will exec opcode CCh which is int 13 ...

God (IA32 protection) forbid if it was INT 13 (disk operations!)... You mean INT 3.
Posted on 2004-04-16 11:04:35 by death
oops yes int 3
Posted on 2004-04-18 22:26:28 by Qages