MinGW - Minimalist GNU for Windows

Sorry, Keith, but you made one thing wrong. The pascal calling convention 
is not identical to the stdcall calling convention. The common feature 
with them is that they both require the callee to pop up the arguments off 
the stack with an instruction like "ret n" (for a __stdcall function named 
func@...), but __stdcall function pushes the arguments right-to-left. Also, 
when there are variant arguments passed to a function declared __stdcall, 
it will behave exactly the same as __cdecl.

Only one gotcha: In MSVC the resulting function will have a name without a 
suffix (exactly the same as __cdecl), but in some older MinGW GCC versions 
the resulting function will have a "@0" suffix. GCC 3.4.2 does not have 
this problem --- a reason to upgrade :-).

Best regards,

Yongwei





Keith MARSHALL <keith.marshall@...>


 
        To:     mingw-users@...
        CC: 
        Subject:        Re: [Mingw-users] [mingw - C/C++] RE: __stdcall cancels the effect of 
extern "C

>> The trailing @number is not C++ decoration.  It is actually
>> one of the things that __stdcall is for.  The number is the
>> number of bytes passed to the routine so that the called
>> routine can clean the stack rather than the caller.
>
> Why would you want to do that?

If you need to ask, you probably don't want to know!

It's dependent on the function calling protocol used by the
compiler.  When the language is C or C++, the calling routine
pushes arguments from right to left on to the stack, calls the
function, saves the return value, and removes the arguments
from the stack.  This protocol is required, to support
functions which can have varying numbers of arguments, and
absolves the called routine from needing any knowledge of
the number of actual arguments passed, (provided sufficient
are provided, to satisfy its needs).

When the language is Pascal, or FORTRAN, the calling routine
pushes arguments from left to right, and calls the function,
subroutine(FORTRAN) or procedure(Pascal); it expects the
called routine to remove its arguments from the stack, *before*
it returns.  This protocol is suitable only for functions,
subroutines and procedures which accept a fixed number and
type of arguments, which, of course, is a limitation imposed
on FORTRAN and Pascal functions, subroutines and procedures.

In the MS-DOS days, Microsoft were heavily committed to the
use of Pascal in their OS development, and this continued into
Windows development; most of the Windows API's use the Pascal
argument passing protocol.

Regards,
Keith.

Wu Yongwei wrote:
> Sorry, Keith, but you made one thing wrong. The pascal calling 
convention 
> is not identical to the stdcall calling convention. The common feature 
> with them is that they both require the callee to pop up the arguments 
off 
> the stack with an instruction like "ret n" (for a __stdcall function 
named 
> func@...), but __stdcall function pushes the arguments right-to-left. 
Also, 
> when there are variant arguments passed to a function declared 
__stdcall, 
> it will behave exactly the same as __cdecl.

Fair enough, Yongwei.  I stand corrected.

I wrote my earlier post on the basis of many years experience
actually writing MS-DOS software using MS-Pascal and MS-FORTRAN,
with MASM functions to do the low level stuff that neither Pascal
nor FORTRAN could manage, so I was completely conversant with the
argument passing protocols, at the MASM ABI level.

I'm curious though;  if a __stdcall function will use a `RET n'
instruction to pop its argument frame off the stack and return to
its caller, how can it cope with variant arguments?  IIRC, the `n'
in the `RET n' instruction cannot be a variable -- it must be a
constant, hard coded directly within the instruction stream, in
the code segment, and therefore the size of the argument stack
frame has to be fixed at assembly time, (for the function, not
its caller).  At this time, the assembler can have no knowledge
of the size of the argument frame which a caller will push, prior
to the call; it must assume that the caller will create a frame
of exactly the right size.  Surely, this can only be guaranteed
if the caller is confined to use a fixed argument prototype.

Of course, it's entirely possible that I have misinterpreted your
reply.  Are you really saying, that if a function is prototyped as
__stdcall, but with variant arguments, that __stdcall is ignored,
and treated as __cdecl instead?  Or is it the case that if variant
arguments are passed, the function will pop the prototyped subset,
leaving the caller to clean up the rest?

Best regards,
Keith.