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
You can think that arg1 is acting as a local variable. Modifying the argument does not cause a problem.
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?
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
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
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.
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
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.
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...
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)