Re: calling convention stdcalll and cdecl call
* Liviu:
"Alf P. Steinbach" <alfps@start.no> wrote
* Liviu:
"Alf P. Steinbach" <alfps@start.no> wrote
* Liviu:
Stdcall does not, can not and could not support variadic functions.
An extension to stdcall could, but at the price of breaking binary
compatiblity with stdcall.
Sorry, but those assertions are rubbish. ;-)
Sorry, but those words are hollow ;-)
Please stop posting rubbish.
But, once you add a requirement that EXX must be preserved/passed
through for some [existing] "stdcall" calls, and recompile client
code using instrument_target to use the new convention, it will badly
fail in those cases.
Yes, it would be stupid, idiotic, braindead, etc. ad nauseam, to
introduce a solution that Does Not Work, imposing new requirements on
existing code.
Right. The instrument_target code, which is language and compiler
neutral, would break because of a change in the semantics of stdcall.
Are you saying the instrument_target code uses stdcall variadic routines,
/before/ support for that exists in the language implementation?
Or are you saying the instrumented code uses such routines, /before/ support for
that exists in the language implementation?
It's infuriating that you're pretending to not grasp the simplest points, and
just go on re-asserting the same old rubbish.
Note that said change (reserving the EXX register) would not affect in
any way the binary code of instrument_target itself (as could be present
in a .lib or .dll), yet it would break unsuspecting client code trying
to use instrument_target like it always did before such a "stdcall"
redefinition.
Why the heck would you reserve the EXX (any E...) register in general?
Which is exactly why no one would ever imagine "extending"
stdcall in a binary incompatible way. Oh well, _almost_ no one ;-)
Just you.
I don't think anyone else is that much into creating code and imagining
solutions that do not work.
Note that e.g. a
void __really __stdcall foo( ... );
would not be affected in this scheme
At the risk of restating the obvious, but "void __knurre foo(...);"
would not break anything at all, in C/C++ or elsewhere.
I presume that's meant as a counter-example to something else breaking.
But in spite of being a master at creating code that does not work, you've still
not reached your goal of breaking any code.
That fact that solutions that do not work are the only ones you admit to
understand does not mean that things cannot work, it only says something about
/you/.
Hence, by not existing, it's not instrumented, not affected: no binary
compatibility is broken by introducing support for them in a
reasonable manner, as opposed to your general changing of stdcall
convention for existing routines.
I was not (and the given example was not) referring to any particular
routine.
And nobody's said you were referring to just a particular routine, and nobody's
assumed you were. Feel happy. You have not been misunderstood in that respect,
at least not here. :-)
It was about an arbitrary stdcall, which covers any function
present or future which conforms to the stdcall convention.
That's not a meaningful statement. What is "arbitrary stdcall" anyway?
What's affected by supporting foo() in a particular way incompatible
with the bad trampoline code, is just that the bad instrumentation
code now only can claim to support non-variadic stdcall functions.
Redundant.
That's not a meaningful statement, in fact, it's malformed as a sentence.
However, on a more constructive note, if we make this more real and
talk about practical solutions for Visual C++, which in a braindead
manner changes the meaning of __stdcall to mean __cdecl in the context
of a variadic function, then in a short-sighted perspective a
practical solution is to call stdcall something else in this contex,
e.g. __stdcallv.
OK, then I'd call this case closed.
You're confused again. But if you're happy, so be it.
So perfectly legit code according to the existing specs
I wonder where the specs are that says which registers a forwarder can
and cannot freely change for stdcall, do you have a reference?
You'll find some at
http://msdn.microsoft.com/en-us/library/aa295770.aspx.
Perhaps Internet Explorer shows more there than my Firefox, but at least in
Firefox there's nothing there about general register usage.
For subsets of
stdcall families (such as the Win32 API) there are more rules, of
course.
Just out of curiousity, do you have any reference of the rules that you say are
in addition to the empty rule set you already provided a link to?
Point is however that anything which is not declared as "used"
or "reserved" is considered to be available for use.
Do you have a reference for that?
Since there is no
register marked as "reserved for future support of variadic functions",
adding one now is not possible - short of changing the spec.
If what you've stated earlier here should turn out to be correct, this
conclusion would still be utter rubbish and idiocy.
Anyways, even though you do seem to like code that doesn't work, if
you want the trampoline to also work with new stdcall variadic
functions (not sure why they would be so important to support compared
to the host of other routines not supported?), the best solution would
be to fix the bad trampoline code.
What's bad about it? It is, again, perfectly correct code under the
stdcall specs.
You've yet to show that your code is correct. Anyways, good code in general has
a property called *robustness*. It doesn't avail itself of pecularities of a
given small context of usage, but is designed to work in general, assuming the
least instead of the most about its environment. Bad code is unable to handle
the slightest provocation or change in usage. Your code was bad: it handled
particular cases, when it could easily have handled a much broader set of cases.
But still your code did not break.
It would just be unable to handle more cases than it already was used for, as is
usual for bad code.
no, no existing code would be broken by just introducing support for
stdcall variadic functions.
However, regarding the latter, possibly some documentation of a very
nasty bad piece of trampoline code would be be exposed as claiming a
little too much.
That's not a big deal, and probably for the best. :-)
So it's no longer "no existing code would be broken", now it's "no
'worthy' existing code would be broken".
The latter quote is not quoting me.
Nor is it representing anything I've written or indicated, nor is it in tune
with reality.
It is a lie.
I rest my case.
Well, that may be a good idea, when you have to resort to umpteen reassertions
of old meaningless rubbish, plus lying (right above).
I don't understand how you can do this.
Cheers,
- 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?