Re: calling convention stdcalll and cdecl call
* Ben Voigt [C++ MVP]:
Since stdcall defines no such mechanism and reserves no location
(hidden param, designated register, stack slot) to accommodate that
additional information, any place you'd choose to pass the info would
have been up for grabs under the existing stdcall convention,
No, not at all. There are only two cases to consider.
Either (1) the language implementation already supports variadic
stdcall routines, in which case it necessarily already does this. :-)
And possibly in a way incompatible with yours.
First, I've posted in a follow-up to you elsewhere that I have no ownership.
Please don't use such intentionally misleading rhetorical techniques in future,
especially after having been notified not to do so. This paragraph is your
second notification about that particular issue. I must assume that you did
understand the first notification, and are therefore now doing it just as a
manipulative technique. TIA for stopping, if you can. I understand that this
manipulative tendency is perhaps ingrained in Microsoft corporate culture, at
least as displayed in this group, but it just takes some willpower to be honest.
Now, re your comment.
In the case of having support for stdcall variadic function in the language
implementation, one would not change the language implementation.
So while your earlier article in this thread displayed good reasoning but
reached the wrong conclusion due to erronous beliefs (you thought C++ supported
non-POD arguments to variadic functions), in this case both your reasoning and
conclusion is simply meaningless, and not due to mistaken beliefs about facts:
you have all the facts at hand, but still manage to produce idiocy.
Perhaps, considering that, I'd better repeat.
In the case of having support for stdcall variadic function in the language
implementation, one would not change the language implementation.
The only way you can guarantee that there is no pre-existing variadic
stdcall code you'd need to maintain compatibility with, is if in fact there
is no such thing as variadic stdcall code.
This is a fallacious generalization, from no support in some hypothetical
language implementation -> no support anywhere.
Because if there were, it could exist,
I'm impressed by this reasoning.
and it could be trivially incompatible with your implementation (for
example, pass the number of bytes in the argument list in a 64-bit integer
vs size_t).
That's the third fallacy in a row. Of course, /you/ might go about changing a
language so it would become incompatible with existing software, as you're
arguing you would. But reasonable, competent folks would not.
Therefore, proof by contradiction, your assumption that there
is no existing variadic stdcall code requires that stdcall is in fact
incompatible with variable argument lists.
That's fallacy number four, as I'm counting. Try to get some sleep, Ben. :-)
Or, (2), it does not, in which case with the language implemention
we're considering extending there are no existing calls to variadic
stdcall functions, no existing such functions, and therefore all at
the machine code level is free, within the constraints of argument
pushing order and stack adjustment.
Cheers,
- Alf
PS: In the follow-up to your eearlier article I wrote that it was "good
reasoning", which it was. I'm now speculating that perhaps, given the manifest
lack of reasoning powers you display above, you may have misunderstood my
comment to mean you had reached a correct conclusion then. You had not, the
conclusion there was just meaningless, due to you having your facts wrong.
--
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?