Managing Parameters Passed to Function

[Astro]

Hi,

Take the following:

http://msdn.microsoft.com/en-us/library/ms683241(VS.85).aspx

Code Select Expand

DWORD WINAPI HandlerEx(
  __in  DWORD dwControl,
  __in  DWORD dwEventType,
  __in  LPVOID lpEventData,
  __in  LPVOID lpContext
);

If I had:

Code Select Expand

ServiceMsgHandler proc CtrlCode:DWORD
Note it is a callback function.

* Is this legal?

* Would it work as expected (e.g. given it is the only parameter in my proc, would it access the first or last value passed)?

I would expect to still ret 10h to clean up the stack (4 DWORDs).

Best regards,
Astro.

[dedndave]

hiyas Astro
>crash<
if the function has 4 parms, you hafta list 4 parms and pop 4 parms
as for the HandlerEx function, i dunno
i haven't got that far, yet   :P

[Astro]

Hi,

I'm happy with the function - just whether I could omit parameters I didn't want.

On reflection I can't see the point and settled with this:

Code Select Expand

ServiceMsgHandler proc CtrlCode:DWORD, EventType:DWORD, EventData:DWORD, Context:DWORD
mov eax,CtrlCode

; code here

ret 10h
ServiceMsgHandler endp

Best regards,
Astro.

[Mirno]

You can omit the names of the "unused" parameters.
This at least shows you that you don't care about them. Of course this will have no effect on the resulting code, so it comes down to style.
If you may need the other variables later, then they are in place, if you don't then they're unnamed and out of the way making that clear.

Code Select Expand

ServiceMsgHandler proc CtrlCode:DWORD, :DWORD, :DWORD, :DWORD

Mirno

[MichaelW]

Omitting the unused parameters will work only if the procedure uses the C calling convention. With STDCALL, doing so can cause a stack imbalance because the convention specifies that the called procedure remove the parameters from the stack, and the procedure has no standardized way of knowing how many parameters were actually passed. With the C calling convention there is no problem with this because the convention specifies that the caller remove the parameters from the stack, and the caller knows how many parameters were actually passed.

[Astro]

...but even if I declared all the parameters in the procedure, how does that help?

If I ret 10h this still removes 16 bytes from the stack before I return, so surely the stack is balanced, whether I declare them in the procedure or not? I don't pop them in my code (in this instance) so they are still there before I return?

Best regards,
Astro.

[hutch--]

Astro,

Basic are ALWAYS BALANCE THE STACK, if a function is designed to accept 4 arguments that are pushed in the normal manner when called, at the cleanup end you need to correct the stack by 16 bytes. Another thing, if you use thye MASM PROC directive, you do not normally use the manual RET format "RET NUMBER" you just use RET.

Now if you code the complete proc yourself AND its a C calling convention, just use RET, if its STDCALL use RET [number] where number is the number of bytes pushed in the first place to call the procedure.

[Astro]

Hi Hutch,

I use:

Code Select Expand

SomeProc proc
SomeProc endp

(I didn't know there was another way), so this case would only require a ret ?

Best regards,
Astro.

[Mirno]

Hi Astro,

If your proc is declared as stdcall (or you don't specify and have stdcall as your standard - as windows generally does), then ret is a macro for "ret x" where x is determined by the number of arguments. If you have a variable number of arguments (ala sprintf type functions - although sprintf itself is C calling convention), then stdcall acts like C calling convention and doesn't clean up itself, but the function caller must do the clean up.

Basically if you use masm's procs and invokes, it will deal with these issues for you. If you want to go really low level (push & call yourself, use labels, set up the stack frame, or disable the prologue and epilogue) then you must do this.

Mirno