The MASM Forum Archive 2004 to 2012

General Forums => The Campus => Topic started by: jojo on August 20, 2005, 09:35:19 AM

Title: Are LOCAL variables initialised?
Post by: jojo on August 20, 2005, 09:35:19 AM
I have been playing cheerfully for a while with some code that used a LOCAL MyCounter:DWORD declaration as a counter. Coming from GFA, I never reflected on the need to assign an initial value to MyCounter - and I never had problems, until I tried in on my old Win98SE machine. Boom, crash! It took me a while to find out that MyCounter started somewhere in megabyte range...
Question: Sheer coincidence that it worked on Win XP, on three different machines? Or is there some precise reason why (apparently) local variables are initialised on XP but not on 98SE?
Thanks for a hint,
Jochen
Title: Re: Are LOCAL variables initialised?
Post by: Petroizki on August 20, 2005, 09:42:32 AM
Local variables are not initialized automatically. Local space is allocated from the stack, which is full of garbage, old return addresses, old parameters etc..

You must initialize the values yourself.
Title: Re: Are LOCAL variables initialised?
Post by: jojo on August 20, 2005, 09:56:07 AM
Quote from: Petroizki on August 20, 2005, 09:42:32 AM
Local variables are not initialized automatically. Local space is allocated from the stack, which is full of garbage, old return addresses, old parameters etc..

You must initialize the values yourself.

Sounds perfectly plausible. I was confused because my code without initialisation had worked perfectly on different machines, and with many thousand code executions; so I was wondering whether there was some new MASM feature that automatically sets them to zero...
Title: Re: Are LOCAL variables initialised?
Post by: hutch-- on August 20, 2005, 10:24:54 AM
jojo,

Petroizki is right, you must always load a LOCAL variable yourself or you have basically random content. If for example you want a zero filled string buffer, you create the buffer the size you want then run a zero fill algo on the address of that local buffer.
Title: Re: Are LOCAL variables initialised?
Post by: jojo on August 20, 2005, 04:30:48 PM
Quote from: hutch-- on August 20, 2005, 10:24:54 AM
jojo,

Petroizki is right, you must always load a LOCAL variable yourself or you have basically random content. If for example you want a zero filled string buffer, you create the buffer the size you want then run a zero fill algo on the address of that local buffer.

Hutch,
What you write makes sense, but what I experience is weird: I call a routine several times, and every time my local variables start with zero. At "ret" they leave with non-zero values, and I also checked the stack pointer: esp remains constant.
Theory would suggest that the first time I get some random values, and the next time I get what I put myself in these local variables (i.e. on the stack). Practice is that the code crashes on Win98SE but not on XP... as if XP offered a helping hand to careless programmers like me ;-)
Title: Re: Are LOCAL variables initialised?
Post by: hutch-- on August 22, 2005, 07:50:11 AM
jojo,

You can be sure that MASM does not initialise local variables at all. It is the specification of a basic compiler to initialise local variables to either null strings or with numeric variables to zero but an assembler does not do that and you don't really want that characteristic as you may want something else other than zero in the variable. Simple rule is to stick what you need into the local before you use it and the code will be reliable across different Windows versions.
Title: Re: Are LOCAL variables initialised?
Post by: Mirno on August 22, 2005, 10:47:45 AM
Seeing as XP is more secure than 9x, I would suspect that it zeros the stack before use.
In theory you could search through the memory that had been de-allocated from other processes by creating a massive stack on 9x and reading through. XP seems to zero the pages first to avoid this spying.

So if you execute your function (that allocates the buffer) on XP as the first function, then the stack is as pure as the driven snow, but if you put code before it then it would polute the stack and you'd see the same crashes.

Mirno
Title: Re: Are LOCAL variables initialised?
Post by: MichaelW on August 23, 2005, 09:12:06 AM
Quote from: Mirno on August 22, 2005, 10:47:45 AM
Seeing as XP is more secure than 9x, I would suspect that it zeros the stack before use.
Seems plausible, but I see no evidence of this, at least for XP HE SP1, for which the app in the attachment displays:

E10C5E38
00000001
00000000
00000001
00000006
77F764A6
77E814C4
FFFFFFFE

E10C5E38
00000001
00000000
00000001
00000006
77F764A6
77E814C4
FFFFFFFE



[attachment deleted by admin]
Title: Re: Are LOCAL variables initialised?
Post by: Tedd on August 23, 2005, 09:34:30 AM
Quote from: Mirno on August 22, 2005, 10:47:45 AM
Seeing as XP is more secure than 9x, I would suspect that it zeros the stack before use.

For the .data? section, I believe it does, but so does 9x :P
For the local stack (as created by adjusting esp when entering a function) this wouldn't be possible.
Title: Re: Are LOCAL variables initialised?
Post by: QvasiModo on August 23, 2005, 03:34:55 PM
Quote from: Mirno on August 22, 2005, 10:47:45 AM
Seeing as XP is more secure than 9x, I would suspect that it zeros the stack before use.

Definitely not. But maybe it zeroes newly allocated pages as the stack grows... I'm just guessing here. In any case it'd have nothing to do with security, but patching common programmer's mistakes.
Title: Re: Are LOCAL variables initialised?
Post by: GregL on August 24, 2005, 02:34:53 AM
MichaelW's program under Windows XP Pro Sp2:

00000001
00000006
EFFF2D04
805824EE
82FF104C
7C90E64E
7C816D4C
FFFFFFFE

00000001
00000006
EFFF2D04
805824EE
82FF104C
7C90E64E
7C816D4C
FFFFFFFE


Press enter to exit...

Title: Re: Are LOCAL variables initialised?
Post by: comrade on August 24, 2005, 04:16:37 AM
Jojo, love your music
you are hot too
Title: Re: Are LOCAL variables initialised?
Post by: Jeff on August 24, 2005, 04:19:58 AM
i get nearly identical numbers as greg on my pro sp2:
00000001
00000006
EDBB5D04
805824EE
82BF004C
7C90E64E
7C816D4C
FFFFFFFE

00000001
00000006
EDBB5D04
805824EE
82BF004C
7C90E64E
7C816D4C
FFFFFFFE