importing C/C++ runtime libraries

[nobody]

I've noticed some particular behavior from some of the functions that I use from LIBC.lib.  For purposes of example, i'll use sprintf() and strcpy().

These functions don't appear to pop their parameters off the stack at the end of the function like all the other functions i've become accustomed to using.  It seems to be necessary to run a serials of "pops" after calling the function, to clear off the stack before i do anything else...

This seems like particular behavior to me, though I'm sure there's a perfectly reasonable explination.

My question is, what functions act this way, why, and is there a straight forward way of knowing which way they're going to act without trial and error?

Thanks, JC

[Frank Kotler]

Sure, it's called the C calling convention, and all the libc functions work like that. It's more usual to "add esp, " than multiple "pop"s to clean up the stack, but either should work.

You must be used to "stdcall" convention, in which callee cleans up stack... (ends with "ret ")... such as the Windows API. (but "wsprintf" is C call - having a variable number of parameters, it has to be - there may be others)

In both C and stdcall, functions are required to "preserve" (put 'em back like you found 'em) - ebx, esi, edi, ebp (and of course esp). Functions are allowed to trash ecx, and edx (if it isn't used for return). Return value is in eax, normally.

If you're interacting with code that uses either of these conventions, you'd better learn and adhere to them!

Not a concern for Nasm, since we don't do 64-bits, but the 64-bit BSD (and maybe others?) use a *completely* different interface!

Best,
Frank

[nobody]

I suspected this was the case, and am glad to see i'm correct.  Thanks for the support once again.