flat assembler
Message board for the users of flat assembler.

Index > Windows > local var in dialog procedure

Author
Thread Post new topic Reply to topic
Alessio



Joined: 26 Sep 2003
Posts: 35
Location: Viterbo, Italy
Alessio
Hi,
I've following dialog proc:

Code:
proc DlgProc,hwnd,msg,wparam,lparam
     local result:BYTE

     cmp [msg],WM_INITDIALOG
     je  .wminitdialog
     cmp [msg],WM_COMMAND
     je .wmcommand
     cmp [msg],WM_CLOSE
     je .wmclose
     xor eax,eax
     jmp .finish

  .wminitdialog:
     mov [result],0   ; set to 0
     xor eax,eax
     jmp .finish

  .wmcommand:
     mov eax,[wparam]
     cmp al,IDC_CLOSE
     je  .wmclose
     xor eax,eax
     jmp .finish

  .wmclose:
     movzx eax,[result] ; why it contains garbage ?
     invoke EndDialog,[hwnd],eax

  .finish:
     ret
endp
    


I don't understand why, in wmclose message, local "result" var contains garbage...

Thank you.
Post 05 Apr 2011, 13:16
View user's profile Send private message MSN Messenger Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3502
Location: Bulgaria
JohnFound
And what you expect to contain? The local variables are defined on stack.
In your procedure "mov [result], 0" happens on different call of the procedure than "movzx eax, [result]" between these different calls the stack pointer might be changed and the stack content as well.
Post 05 Apr 2011, 13:20
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17467
Location: In your JS exploiting you and your system
revolution
Local variables do not provide persistence between calls because other code can use the same piece of stack memory and trash anything you were trying to put there.

You have no option but to create a global label to give you the persistence you want.
Post 05 Apr 2011, 13:32
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7751
Location: Kraków, Poland
Tomasz Grysztar
In the first post in this thread: http://board.flatassembler.net/topic.php?t=10518 (near the end of post) you can find the window_prologue/window_epilogue macros that extend "proc" directive in such a way that it defines window procedure that stores its local variables in a memory block allocated upon window creation. This allows to have variables local with respect to window and not just to a single procedure call.
Post 05 Apr 2011, 14:14
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Just to add a little more, the variables defined by proc are not of this kind: http://en.wikipedia.org/wiki/Local_variable#Static_local_variables

Perhaps local/locals could be extended to provide static local variables and let .end allocate the space with a separate R/W section? (and optionally expose a macro to give the opportunity to deploy the variables on an existing section)
Post 05 Apr 2011, 16:13
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7751
Location: Kraków, Poland
Tomasz Grysztar
LocoDelAssembly wrote:
Perhaps local/locals could be extended to provide static local variables and let .end allocate the space with a separate R/W section? (and optionally expose a macro to give the opportunity to deploy the variables on an existing section)
This should be done with customized prologue/epilogue, just like the example I provided. Also see section 3.1.5 of FASM.PDF, which is the same as section 1.5 of online "Windows programming headers" documentation.
Post 05 Apr 2011, 17:42
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Tomasz, I meant as part of the official package code base. Still, I think that doing what section 1.5 says is not enough, as I didn't mean ALL locals to be declared as static, but only those tagged as such (i.e. at least two localbase@proc are needed here.) Or is still possible by just using what is documented there?
Post 05 Apr 2011, 18:18
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
Loco: remember that FASM can't combine sections itself. How exactly do you expect the ".end" macro to place these variables into data section? Or do you think it is okay for official macro to create extra section for these variables?
Post 05 Apr 2011, 18:33
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
vid, yes, extra section, I've called it "separate R/W section" earlier. I think it is an acceptable inefficiency for the extended headers that are meant to make programming easier. But still, letting override the placement of the variables would be a welcomed feature.
Post 05 Apr 2011, 18:42
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
FASM already has enough problems with non-standard executable layout (and thus false virus alarms, incompatibility with poorly written tools, etc.). Extra section would only make this worse. And being able to conveniently limit scope of global variable to high-level procedure is little payoff for assembly. Once you decide to write in assembly, quality of your product should be in focus, not ease of development. For that, use HLL.
Post 05 Apr 2011, 19:01
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Alessio



Joined: 26 Sep 2003
Posts: 35
Location: Viterbo, Italy
Alessio
Thank you all for answers.
I've another silly question...local variables are initialized to zero ?
I've not found this kind of info into manual.

Thanks.
Post 15 Apr 2011, 08:58
View user's profile Send private message MSN Messenger Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3502
Location: Bulgaria
JohnFound
No they are not (of course). The local variables are simply part of the stack, allocated for use from some part of the program.
This memory is filled with information, pushed there from other parts of the program on previous call/push instructions.

Of course, one can write macro to zero this memory on the input of the procedure, but IMHO, this would be not good idea, because of 2 reasons:
1. you don't need all your variables to be 0 - so, you still need to initialize them with the proper values - why to make it twice?
2. Assembly language programming relies on the clearness. It is not good practice to process data in hidden manner - through macros.

The proper solution (if you like such things) would be macro "clear" that you can use to clear the local variables explicitly.
But "mov [var], 0" is not longer to type, but is more readable - besides the action it demonstrates also how it is done.
Post 15 Apr 2011, 09:23
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
shoorick



Joined: 25 Feb 2005
Posts: 1607
Location: Ukraine
shoorick
no. if you wish to initialize them you have to do it with your code.


Last edited by shoorick on 15 Apr 2011, 10:04; edited 1 time in total
Post 15 Apr 2011, 09:24
View user's profile Send private message Visit poster's website Reply with quote
Alessio



Joined: 26 Sep 2003
Posts: 35
Location: Viterbo, Italy
Alessio
Thank you all for answers.
I've another silly question...local variables are initialized to zero ?
I've not found this kind of info into manual.

Thanks.
Post 15 Apr 2011, 09:44
View user's profile Send private message MSN Messenger Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
goto 128048
Post 15 Apr 2011, 10:41
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.