Hi Group Members,
I am Struck with a Problem. I want to pass Variable number of Parameters to a Procedure in "TASM". I have to Program a Function that can accepts any no of Parameters. But I could not know how to Implement it. Just like "printf" in "C".Please help me.
I am Struck with a Problem. I want to pass Variable number of Parameters to a Procedure in "TASM". I have to Program a Function that can accepts any no of Parameters. But I could not know how to Implement it. Just like "printf" in "C".Please help me.
Example:
wsprintfA PROTO C :DWORD,:VARARG
wsprintfA PROTO C :DWORD,:VARARG
Example:
wsprintfA PROTO C :DWORD,:VARARG
Ya, I know how to declare it, but do not know how to access the Parameters. And also could you explain it in TASM IDEAL Mode how to do it. Suggestions will be appreciated.
The parameters could be easily accessed like (without stack frame)
If there is stack frame, use ebp instead of esp.
mov reg,[esp+4];first parameter
mov reg,[esp+8];second parameter
mov reg,[esp+16];third parameter and so on
If there is stack frame, use ebp instead of esp.
The parameters could be easily accessed like (without stack frame)
mov reg,[esp+4];first parameter
mov reg,[esp+8];second parameter
mov reg,[esp+16];third parameter and so on
If there is stack frame, use ebp instead of esp.
Hi roticv,
The Parameters can be accessed by the above way if we know in Advance the number arguments the calling Program is passing. But the procedures like "printf", "scanf" doesn't know how many arguments it can expect.
For Example,
IDEAL
-
-
CALL print, "Some Elements Are:%d %d",Param1,Param2
-
-
CALL print, "The Elements are:%d %d %d %d",Param1,Param2,Param3,Param4
-
PROC print,Format_String:NEAR PTR BYTE,Parameters:Vararg <---- Like this
-
-
But in the PROC declaration we can't use VARARG to get variable number of parameters,as we do in the MACROS.
I need some Method to access variable no of Parameters.
mov edi,esp
invoke varargfunction,param1,param2,.......
sub edi,esp
add esp,edi
I used edi but you can use any register that is unaffected by the function or a variable if you like. If you want to know the number of arguments - edi contains the number of bytes (plus stackframe when inside the function) pushed onto the stack, the rest is just math.
invoke varargfunction,param1,param2,.......
sub edi,esp
add esp,edi
I used edi but you can use any register that is unaffected by the function or a variable if you like. If you want to know the number of arguments - edi contains the number of bytes (plus stackframe when inside the function) pushed onto the stack, the rest is just math.
Well, for your example function I doubt there is a need to get the number of parameters passed onto the stack. For example
http://www.madwizard.org/snippets/viewSnippet.php?s_ID=65
http://www.madwizard.org/snippets/viewSnippet.php?s_ID=65
donkey,
Isn't SUB EDI,ESP followed by ADD ESP,EDI, equivalent to MOV ESP,EDI? I use structures instead of stack frames to reference parameters.
prasad_86,
There is no way a called variable number of parameters sub-program can know how many parameters you sent it unless you tell it. In WSPRINTF, the format statement indicates how many parameters are needed. If you supply more parameters than needed, WSPRINTF ignores the extra parameters. If you don't supply enough, WSPRINTF takes parameters from the area of stack it should not, and the results are undefined. In all cases, a program calling WSPRINTF is responsible for cleaning up the stack, because it PUSHED those parameters on in the first place. One way around this problem is to PUSH another parameter onto the stack giving the number of parameters to follow. WSPRINTF does not do that. Ratch
Isn't SUB EDI,ESP followed by ADD ESP,EDI, equivalent to MOV ESP,EDI? I use structures instead of stack frames to reference parameters.
prasad_86,
There is no way a called variable number of parameters sub-program can know how many parameters you sent it unless you tell it. In WSPRINTF, the format statement indicates how many parameters are needed. If you supply more parameters than needed, WSPRINTF ignores the extra parameters. If you don't supply enough, WSPRINTF takes parameters from the area of stack it should not, and the results are undefined. In all cases, a program calling WSPRINTF is responsible for cleaning up the stack, because it PUSHED those parameters on in the first place. One way around this problem is to PUSH another parameter onto the stack giving the number of parameters to follow. WSPRINTF does not do that. Ratch
Yeah, but I only showed it that way to demonstrate how to find the number of bytes pushed onto the stack, not to show how to code it.