Re: calling convention stdcalll and cdecl call
Alf P. Steinbach wrote:
* Ben Voigt [C++ MVP]:
[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.
This statement could easily be misinterpreted by some reader other
than me, due to the quoting technique you employed here.
The four fallacies were mentioned in the context of your previous
article, call it X, not the one you're talking about above, and we're
talking about here, call it Y, with numbered points.
In article Y I though the reasoning was fine, but premise #1 didn't
hold.
Well, both my posts used the same argument, although my presentation wasn't
so clear the first time. Yet the first conclusion still holds -- it's not
possible for any variadic stdcall to guarantee compatibility with existing
stdcall code. You have however, made a very convincing argument that
compatibility with other stdcall code isn't a fundamental requirement, as
supported by your evidence of the Microsoft compiler generating machine code
that doesn't follow the documented rules and isn't compatible with other
code (which I checked by compiling your example with VC++ 2005 SP1, the
/EHsc option was needed but it came up with exactly what you posted -- I
didn't doubt that it would, but I wanted to inspect the call site which you
hadn't posted).
Now that we've pinned each other down and forced each other to use precise
terms and no hand-waving, I find myself in total agreement with you (at
least on your conclusions, not whether a new variadic calling convention is
needed):
That "being stdcall" is too weak a statement to be testable, you've proven
quite clearly.
Also, as you so succinctly wrote:
What would be Good would IMHO be
* An authoritative definition of what registers must be preserved
by function (two different sets are stated by Microsoft, natural
choice would be the smallest one, which I think is also the
latest, in order not to break code).
* An authoritative definition of what registers can be clobbered by
e.g. a trampoline function such as Liviu suggested (natural
choice would be none, then let non-conforming code, if any, fight
it out in market).
* An authoritative definition of how non-static member function's
this pointer is passed, and perhaps ditto for args total size for
variadic function.
* An authoritative definition of for which argument types the
stdcall convention requires a certain way of passing them /
returning them. This is the essential thing saying that if you
have routine with such restricted signature, you really know how
to call it at machine code level, irrespective of tool.
* And what it allows (tool-dependent) for other argument types.
and not the least, as I think you're saying above and as I've
lamented on (is that correct English?) several times in this thread,
* A *clear separation* of what's specific to Windows API stdcall
("general stdcall"), what's specific to MSVC "C", and what's
specific to MSVC "C++".
I agree. I think for that last, what we need is at least a rule to identify
function parameter types/return type that *will* follow the documented "C"
rules without any hidden parameters.
I think MS is gonna have one hell of a hard time implementing C++0x rules
for standard layout types (while your Blah struct isn't POD under C++03 or
C++0x, it is standard-layout in C++0x) wrt calling conventions unless they
totally give up on backward compatibility. But name mangling and such have
always been subject to change between compiler versions. I suspect if we
try a VC++ compiler in a couple years, it will produce the same code as g++,
no hidden argument with an address for the return value.
plus of course linking from all the five or six or more current pages
to one common page.
It might seem a little bit late for this, as we're passing over into
x64 world.
But I think x86 32-bit code will continue to be produced and
maintained for a few years still.
Cheers,
- Alf