Oh, you think that the number of varargs can be calculated from the fmt?

What would you think it could happen here then?

Code:

wsprintf(buff, person.showAge ? "Person %u works at %s, and is %u years old" : "Person %u works at %s. Age can't be disclosed",\
         person.id, person.department, person.age);    

Code:

.
.
.

fmtTab   dd fmtNoAge, fmtAge

fmtAge   db "Person %u works at %s, and is %u years old", 0
fmtNoAge db "Person %u works at %s. Age can't be disclosed", 0

.
.
.

      cmp     [person.printAge], 0
      setne   cl
      movzx   ecx, cl
      mov     ecx, [fmtTab+ecx*4]

      ccall   wsprintf, buff, ecx, [person.id], [person.department], [person.age]

.
.
.    

Azu wrote:

Dunno but they do. Try this

mov edi,esp
push 1
call Sleep
sub edi,esp
jnz Sleepy
int3
Sleepy:
push -1
call Sleep

It will crash every time. If the normal Windows functions didn't pop the args off, it would just sleep forever.

Well, that is just normal stdcall. It will always pop the 1 parameter from the stack. But consider what happens if you push 2 parameters and then call Sleep? The stdcall function will only ever pop off the expected amount of parameters as required from the function definition. So when we try to move this into wsprintf then we are REQUIRED for declare, at the start of the function, how many parameters to pop off the stack, that is what stdcall does for us. So with vararg functions we have NO WAY to declare a vararg parameter. Therefore we HAVE TO choose another calling standard for vararg functions.

All of your code above is fine for assembly programmers, but HLL imposes restrictions that make some things impossible to do.

push somearg
push someotherarg
push 35
push omgsjnwet
call cdeclfunction
add esp, 10h


cdeclfunction: 
push ebp
mov ebp, esp

mov edi, edi   

leave
retn    

push somearg
push someotherarg
push 35
push omgsjnwet
push 14h     
call azufunction 


; this is probably the easiest form of a vararg function which manages its own stack
azufunction: 
push ebp
mov ebp, esp

mov edi, edi

leave
pop ecx
add esp, [esp] ; arg1
jmp ecx    

push somearg
push someotherarg
push 35
push omgsjnwet
call azufunction2 

; very small example of what i mean.
azufunction2: 

pop eax
test eax, eax
je .UnInitialized ; if its NULL we don't pop off those 3

pop ecx
pop edx
pop eax

.UnInitialized:

retn    

i didn't really bother reading most of what you guys wrote but from an optimization standpoint cdecl is a considerably better option then what your suggesting.

cdecl

Code:

push somearg
push someotherarg
push 35
push omgsjnwet
call cdeclfunction
add esp, 10h


cdeclfunction: 
push ebp
mov ebp, esp

mov edi, edi   

leave
retn    

azdecl

Code:

push somearg
push someotherarg
push 35
push omgsjnwet
push 14h     
call azufunction 


; this is probably the easiest form of a vararg function which manages its own stack
azufunction: 
push ebp
mov ebp, esp

mov edi, edi

leave
pop ecx
add esp, [esp] ; arg1
jmp ecx    

because you (or the compiler) still need to know the number of args to pop off the second calling convention adds no benefit over cdecl while increasing the size of the executable, and it also may noticeably slow down your program as well.

also, what you describe (popping them off as you need them) is not actually a calling convention but a programming practice, calling conventions are just the way parameters are passed, who manages stack, and what registers are preserved, also what you wrote it will get increasingly more complex if you need to use an argument in more then one spot, and should an argument be passed but NOT used things get even worse.

for example

Code:

push somearg
push someotherarg
push 35
push omgsjnwet
call azufunction2 

; very small example of what i mean.
azufunction2: 

pop eax
test eax, eax
je .UnInitialized ; if its NULL we don't pop off those 3

pop ecx
pop edx
pop eax

.UnInitialized:

retn    

p.s. hi

proc DllMain hInstance, reason, lpReserved

   pop eax ; hinst we don't need it so we just trash it
   pop eax ; reason
   cmp eax, DLL_PROCESS_ATTACH
   JNE .next

   call DllInit

   jmp .quit

.next:
   cmp eax, DLL_PROCESS_DETACH
   JNE .quit

   call DllUnInit

.quit:
    mov  eax,TRUE
    retn
endp    

not wrong number of args, just unused args. not all arguments are always used in a function and they are certainly not always used in the same order they are pushed. another (more common) example is this:

Code:

proc DllMain hInstance, reason, lpReserved

   pop eax ; hinst we don't need it so we just trash it
   pop eax ; reason
   cmp eax, DLL_PROCESS_ATTACH
   JNE .next

   call DllInit

   jmp .quit

.next:
   cmp eax, DLL_PROCESS_DETACH
   JNE .quit

   call DllUnInit

.quit:
    mov  eax,TRUE
    retn
endp    

DllMain DOES take 3 arguments, so its the right number, but i am only interested in the reason so the first gets trashed (unless i want to spare a register or use some local var) and the third is never popped

having to ALWAYS use every argument and in the exact order they were pushed when creating functions using that standard is somewhat limiting don't you think? additionally local variables will be considerably more tricky to pull off if all you do to grab the args is 'pop reg'

honestly it would be way to much trouble as your code will most likely be more bulky and slower then using another standard not to mention the others don't have the same limitations.

No, there is no reason for it to use them backwards or whatever, that is not how the function works.

The way it is NOW is bulky and slow and bloated.. it would be smaller/faster without the cdecl junk.

Azu wrote:

No, there is no reason for it to use them backwards or whatever, that is not how the function works.

if you do not pop them off in the right order, you will end up with the wrong argument. if you tried to pop off argument 7 when you have only popped of 3 before, you will have to pop off the other 3 in between before you can get to 7 with how you do it.

Azu wrote:

The way it is NOW is bulky and slow and bloated.. it would be smaller/faster without the cdecl junk.

i do not see how adding a single instruction after a function call can be considered bulky slow and bloated, what you suggest can only ever add more to its size and execution-time because you need to save the arguments *somewhere* if you ever plan to use them again and you need to save where your going to return to *somewhere* (or you will pop it off) and you need to re-do how local variables work (because if all you do to grab arguments is 'pop reg' you will end up popping off ebp) all those modifications to the function should add considerably more then what cdecl tacks on.

In the vararg function they are all used, since you only pass as many args as you specified in the input string. There aren't a set amount of args. There is no reason to pass ones it won't be using.

function void printPerson(Person person)
{
  char *fmt;

  if (person.showAge)
    fmt = "Person %u works at %s, and is %u years old";
  else
    fmt = "Person %u works at %s. Age can't be disclosed";

  printf(fmt, person.id, person.department, person.age); /* Single point of call for both fmt strings */

  return;
}    

3       lea eax,[arg3] 
4       push eax
7       push [arg2]
10      push [arg1]
15      call wvsprintfA            
16      retn    

6       pop [return_addy] 
7       pop eax
8       pop ecx
10      mov edx, esp ; lea arg3... i think. 
13      add esp, 4
14      push edx  ; lea arg3
15      push ecx  ; arg2
16      push eax ; arg1
21      call wvsprintfA 
27      push [return_addy]
28      retn    

you only write to the buffer once in wsprintf? you only read from the format once in wsprintf? i'm pretty sure there are more vararg functions then the *printf series.

calling convention:

1. you can't read more then once from an argument

2. you have to have the arguments in the EXACT order they are used

3 you always need to use every argument

not to mention the added measurements for correctly returning and local variables.

currently wsprintf looks like this in cdecl format

*note* push ebp/mov ebp,esp and ending pop ebp removed from both
*note* also those numbers at the beginning are how many bytes it have been used

Code:

3       lea eax,[arg3] 
4       push eax
7       push [arg2]
10      push [arg1]
15      call wvsprintfA            
16      retn    

using your format it might look something like this

Code:

6       pop [return_addy] 
7       pop eax
8       pop ecx
10      mov edx, esp ; lea arg3... i think. 
13      add esp, 4
14      push edx  ; lea arg3
15      push ecx  ; arg2
16      push eax ; arg1
21      call wvsprintfA 
27      push [return_addy]
28      retn    

The calls with person.showAge equal to zero are valid in the code above and in the two codes I have posted earlier. Also, it is supposed to be right doing so, not some kind of safe to protect buggy code.

If anything there are less measurements. Have you taken a good long look at the wvsprintf function (which wsprintf is actually just a wrapper for)? It's a mess.

Exactly like all of the other Windows functions.

It doesn't need to, and doing so would be wasteful. Why read the same thing from main memory multiple times when you are only going to use it once?

You have to put the arguments in the right order the way it is now, too. It can't read your mind.

If anything there are less measurements. Have you taken a good long look at the wvsprintf function (which wsprintf is actually just a wrapper for)? It's a mess.

Huh? Mine isn't a wrapper function. It's standalone. And in my format it would be much smaller/faster then wvsprintf alone, yet alone wsprintf+wvsprintf..

wsprintf(5,"hi %s %i %d %f %x",szString,iInt,iInt,fFloat,lHex);    

add esp,arg1*4    

ret arg1*4