Re: calling convention stdcalll and cdecl call
* Ben Voigt [C++ MVP]:
Alf P. Steinbach wrote:
* Ben Voigt [C++ MVP]:
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.
Unless Microsoft should choose to "standardize" it (de facto) by e.g.
using a specific way of implementing it in some Windows API.
Then other vendors' tools would have to get into line.
And it still wouldn't be compatible with *existing* code.
Except for the "still", right.
If MS did this it could potentially force other vendors to break compatibility.
However, it's not a practical problem, just an amusing hypothetical one.
Just as a C99 compiler isn't compatible with K&R code.
Right, I think (I'm not /sure/ about whether it can't compile K&R code, because
for example g++ is implemented using K&R or K&R-like syntax e.g. for args).
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)
Huh, you think it's needed?
No, I agree with Igor, Alexander, and Liviu that the cdecl convention is
perfectly adequate for the variable argument case.
It's fine that you all agree with me on this onr point. :-)
I explicitly stated this to you just one article back (or perhaps it was two,
whatever), and then earlier still, and so on up to the start of this subthread.
Evidently also you can be blind.
Cheers, & hth.,
- Alf
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?