Re: calling convention stdcalll and cdecl call

"Alf P. Steinbach" wrote:


I think that this whole thread does exist only due to different
understanding of a terminology. Clearly, all participants are
perfectly aware of the ways how compiler passes parameters to a
function and how calling stack is popped up.

The only point that raises an argument is how to call it. I
couldn't find a formal definition of what the calling convention
is. It is, well, a mere convention, which is accepted by major
compiler vendors. So there is a certain flexibility when one could
draw a line between a calling convention and documented function
requirements.

You claim that a special additional argument (which may be
arragnged either manually or automatically by the compiler) still
leaves a function within the boundaries of the same calling
convention, namely __stdcall. That the special meaning of the
argument is up to the function and has nothing to do with a
calling convention.

In my opinion, such interpretation of a calling convention is too
broad and vague. All the more so, if we intend to require an
automatic support by the compiler. I think that once a calling
mechanics is altered, then the convention is breached. By calling
mechanics I mean a number of registers involved and their roles
during a call and obligations that caller and callee have to
fulfill.

That's why, for instance, there is additional calling convention
__thiscall, which is not different from __stdcall, apart of the
special role of ECX register. Authors of the compiler chose to
give a new name to this small alteration of __stdcall calling
convention since there is a new factor that tools must take into
account.

According to my understanding of what a calling convention
consists of, your example is beyond the limits of __stdcall
capabilities because it requires new convention about the meaning
of parameters.

Alex