News:

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

Modifying stack args

Started by jj2007, September 26, 2009, 08:16:58 AM

Previous topic - Next topic

jj2007

Simple question: Could modifying arguments passed on stack as shown below cause any (OS-related) problems?

Quoteinclude \masm32\include\masm32rt.inc

MyTest   PROTO: DWORD, :DWORD

.code
AppName   db "Masm32 is great!", 0
Hello   db "A message:", 0

start:
   invoke MyTest, offset AppName, addr Hello
   exit

MyTest proc arg1:DWORD, arg2:DWORD
  mov arg1, chr$("Masm32 is wonderful!")
  MsgBox 0, arg1, arg2, MB_OK
  ret
MyTest endp

end start

Vortex

You can think that arg1 is acting as a local variable. Modifying the argument does not cause a problem.

sinsi

I've used args as local storage before with no problems. I can maybe see a problem if the caller does something odd but not the OS.
Do you have a problem jj or is it idle curiosity?
Light travels faster than sound, that's why some people seem bright until you hear them.

jj2007

Quote from: sinsi on September 26, 2009, 08:35:02 AM
I've used args as local storage before with no problems. I can maybe see a problem if the caller does something odd but not the OS.
Do you have a problem jj or is it idle curiosity?

Idle curiosity. Some HLL languages choke when you try that...
Thanks for reassuring me :bg

dedndave

that's because you can never tell if they are passing the argument or a pointer to it - lol
C tends to be over-bloated because they lean too much toward pointers, when the argument would do
good to see you on Jochen
Z sends a kiss

sinsi

Hmm...I was talking about using a dword arg as temp storage, but I think you dave are talking about using the target.
Reassure me here jj.
Light travels faster than sound, that's why some people seem bright until you hear them.

dedndave

what i was thinking was that a C program might push an arg on the stack, then use it again, assuming it to be unmodified
an example is, it passes a pointer to a variable for one call, then,
because it may use the same variable for the next call, assumes the pointer is still on the stack
for instance: y = 2x^2 + x + 2
it will pass a pointer to x to square it, then again to add it
same var - leave it on the stack and don't pop it off

in assembler, the arguments are rarely treated this way, although they could be if desired
i would think, as long as you are popping all the arguments off at the end of the routine, it is safe to modify them

sinsi

Well, that was one of my odd occurences...cdecl is different (to me) in that the caller 'owns' the args, since it has to clean up the stack after the call.
Light travels faster than sound, that's why some people seem bright until you hear them.

jj2007

Quote from: sinsi on September 26, 2009, 03:21:04 PM
Hmm...I was talking about using a dword arg as temp storage, but I think you dave are talking about using the target.
Reassure me here jj.

See my example on top of this thread. I modify what I find on the stack, and under normal circumstances that should indeed pose no problems - even if it is a pointer. However, on one occasion I also reuse these args in a different proc; that is definitely bad practice but the only alternative would be a global variable...

dedndave

well - as it is written, they are discarded when you are done with them
i see no problems
(don't go by what i say, though - lol)