Re: calling convention stdcalll and cdecl call
[snip]
And second, your article contained four individual fallacies which I
pointed out individually, no one individual pointing-out-of-fallacy
relying on others.
Well, by assigning neatly numbered points to each sequential piece of the
argument, I think we've shown the argument is valid, you contest one of the
premises. Which is quite different from having four fallacies, but that is
the advantage of laying things out so neatly.
I'm now going to quote you out-of-order but I think not out of context.
[snip]
QED, by contradiction of consequence #3 with point #1.
Point #1 does not hold. :-)
Ok, now that we've gotten that squared away, we can address only Point #1 in
the future.
[snip]
I will present my argument in a simpler form to make it easier to
respond to.
Good, thank you.
Premise #1 -- An calling convention implements stdcall iff it in
binary compatible with every other conformant implementation.
This either places very strong constraints on "binary compatible", or
is simply wrong.
In general it's simply wrong -- but see comment at end of this
section below.
Although I don't consider mangled names to be part of stdcall
convention, first example that binary compatibility doesn't hold for
that. g++ produces mangled name "__Z3food@8" for "void __stdcall foo(
double ) {}", whereas MSVC produces mangled name "?foo@@YGXN@Z". I'm
sorry for addressing since you don't bring it explicitly up, but the
vagueness of "binary compatible" means it could mean just about
anything, so, if you need even more forceful arg about that, consider
e.g. not-mangled names of MessageBox routines in user32.dll.
Arguing against myself, it's not unreasonable to consider /C/ mangled
names as part of stdcall convention.
What if we restricted ourselves to "only calls made through a raw function
pointer (i.e. not functor, not pointer-to-member)"? Then we get rid of the
whole "locating-the-function" issue and focus on "calling-the-function".
Arguing back against myself, hey, that's a neat notion, but only for
a subset of cases; e.g. it falls flat on its face when compared to
the Windows API reality, where names are not mangled that way, but
are certainly stdcall.
Then, if hopefully that's a complete enough exposition of the
mangling as part of convention or not (yes in some cases, no in
general, e.g. for Windows API), example of different machine code for
same __stdcall routine.
#include <iostream>
struct Blah { int x; Blah(): x(666) {} };
Blah __stdcall foo() { Blah x; return x; } // This
routine.
int main()
{
Blah const b = foo();
std::cout << b.x << std::endl;
}
Here g++ (default options) returns the result in register EAX,
Looks like g++ has chosen sizeof(x) <= sizeof (EAX), if I might be so bold
as to illegally mix sizeof with a register name -- it's not valid C nor
assembler, do we all understand what this pseudo-code expression means?
.def __Z3foov@0; .scl 2; .type 32; .endef
__Z3foov@0:
push ebp
mov ebp, esp
mov eax, 666
pop ebp
ret
while MSVC (default options) employs RVO where the caller must supply
the address where the result should be placed,
Looks like VC++ has chosen sizeof(x) > sizeof (EAX), we might ask ourselves
why, but in that case the binary compatibility problem stems from having
arguments with different layouts, not compiler-dependent choices in how to
implement the calling convention. Or something, because it looks like size
= 4 for the return value.
_x$ = -4 ; size = 4
___$ReturnUdt$ = 8 ; size = 4
?foo@@YG?AUBlah@@XZ PROC NEAR ; foo
push ebp
mov ebp, esp
push ecx
lea ecx, DWORD PTR _x$[ebp]
call ??0Blah@@QAE@XZ ; Blah::Blah
RVO is not used, it would have eliminated the argument x and directly
constructed the return value at [ebp + __$ReturnUdt$__].
But it constructs in the local variable space (< ebp).
mov eax, DWORD PTR ___$ReturnUdt$[ebp]
mov ecx, DWORD PTR _x$[ebp]
And here it copies the variable x to the return code whose address is in the
parameter space (> ebp). No RVO.
mov DWORD PTR [eax], ecx
mov eax, DWORD PTR ___$ReturnUdt$[ebp]
And it also returns the value in eax, like g++ does.
mov esp, ebp
pop ebp
ret 4
I hope you understand this, that in the g++ case above the caller
pushes nothing, calls foo() and gets a result back in register eax,
while in the MSVC case the caller must push the caller's result
storage address before calling foo, i.e., that the generated machine
code for the two tools *is not binary compatible* in spite of both
tools generating perfectly acceptable stdcall.
So it appears. But struct Blah is not POD in C++03 due to the existance of
a constructor, so it's not particularly relevant to any discussion on
variadic functions (I learned my lesson about passing non-PODs to variadic
functions -- the standard forbids it!).
I can elaborate if you want, but the point is, evidenced by facts
above, your premise #1 is simply wrong in general -- although, I
hasten the emphasise, it *is* an important consideration for a large
subset of cases.
I agree. We do need to define what it means to be stdcall better.
Otherwise we could say that fastcall and cdecl functions are stdcall, which
we know isn't true in general.
It's quite natural to make such a mistaken generalization.
But now, perhaps you know better, yes? ;-)