News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

Are LOCAL variables initialised?

Started by jojo, August 20, 2005, 09:35:19 AM

Previous topic - Next topic

jojo

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

Petroizki

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.

jojo

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...

hutch--

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.
Download site for MASM32      New MASM Forum
https://masm32.com          https://masm32.com/board/index.php

jojo

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 ;-)

hutch--

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.
Download site for MASM32      New MASM Forum
https://masm32.com          https://masm32.com/board/index.php

Mirno

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

MichaelW

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]
eschew obfuscation

Tedd

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.
No snowflake in an avalanche feels responsible.

QvasiModo

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.

GregL

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...


comrade

Jojo, love your music
you are hot too

Jeff

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