Re: sub esp, 0ch question

No, if it was a char array, the length would be 192. The rep stos
instruction implicitly acts on a dword array (which you can tell
because it was "dword ptr [edi]" and not "byte ptr [edi]").

I'm not sure what you're trying to say. The disassembly definitely
initializes *some* block of memory of size 192 bytes / 48 dwords,
but the question is why. It's definitely not a string since it's
not null-terminated nor is it used in the printf calls or anywhere
else in the function. Blocks of memory like this could be local
variables (which are collectively just a chunk of memory), a stack
guard, a minimum local stack frame... could be lots of things. What
purpose would your pseudocode szData serve?

David


Scherbina Vladimir wrote:
The second idea (which also might be correct) is that those 3 lines of code initializes the memory chunk of length 48 - string array to 0CCCCCCCCh

something like:

[psuedocode]
char szData[48] = {0xcc};
[/psuedocode]

--
Vladimir

"David Jones" <ncic@xxxxxxxxxx> wrote in message news:aaPlg.49261$ZW3.5474@xxxxxxxxxxxxx

00411A22 B9 30 00 00 00 mov ecx,30h
00411A27 B8 CC CC CC CC mov eax,0CCCCCCCCh
00411A2C F3 AB rep stos dword ptr [edi]

storing 0CCCCCCCCh value to edi (the length of edi is 30h)

========================================================
What is the purpose of the above 3 lines?

I'm guessing, just based on the output, that you use Visual Studio.
The Microsoft compiler initializes all variables to this value in
Debug builds so that you can catch uninitialized variables. The
rep stos instruction does this all in one shot as opposed to setting
each variable individually.

However, you don't have local variables, and the posted disassembly
doesn't use this space, so the best I can figure is that this buffer
is used as a guard to look for stack corruption. Or, it could be
that Debug builds have a minimum local stack size so that recursion
problems get caught quicker. Regardless, the compiler was creating
a buffer on the stack and these lines initialize it.

The 0x30 comes from the fact that the compiler was reserving 0xC0
bytes for local stack storage and 0xC0 / sizeof(DWORD) = 0x30.

The particular value, 0xCCCCCCCC, comes from (I think) the fact
that the debugging instruction "int 3" is encoded as the single
byte 0xCC, so if your code happens to fall into here, it will
immediately break into the debugger. But that's just a guess.

David



.

Relevant Pages

  • Re: Looping through array, deleting elements
    ... instruction has two attributes, parm and arg. ... the loop is looking at element x foo, ... foo get's deleted, the array is shifted left, array pointer has not ... and now array pointer is pointing at element z foo. ...
    (comp.lang.ruby)
  • Re: Looping through array, deleting elements
    ... instruction has two attributes, parm and arg. ... the loop is looking at element x foo, ... foo get's deleted, the array is shifted left, array pointer has not ... and now array pointer is pointing at element z foo. ...
    (comp.lang.ruby)
  • Re: Looping through array, deleting elements
    ... You are modifying the array as you iterate over it ... instruction has two attributes, parm and arg. ... the loop is looking at element x foo, ... and now array pointer is pointing at element z foo. ...
    (comp.lang.ruby)
  • Re: many Array creations are slowing down
    ... steady execution timing. ... If you change it to a.push; instruction, ... Preallocate the Array's size and avoid the costs of "growing" the array ...
    (microsoft.public.scripting.jscript)