Re: calling convention stdcalll and cdecl call
* Liviu:
"Alf P. Steinbach" <alfps@start.no> wrote in message
news:LOmdnQIqtJm6xB_VnZ2dnUVZ_qXinZ2d@posted.comnet...
* Liviu:
"Alf P. Steinbach" <alfps@start.no> wrote in message
news:P4KdnTkCvom42B_VnZ2dnUVZ_hWdnZ2d@posted.comnet...
* Liviu:
"Alf P. Steinbach" <alfps@start.no> wrote
* Liviu:
And what's knurre(1, 101, 102, 103) if not a crash.
It's a precondition (function contract) violation.
It's the same as writing printf( "%d" ).
No, if anything, it's the same as writing printf("%d", 1, 2, 3).
No, it isn't. In C99 that printf call is well-defined: you're not
lying to the function. In the case of the call to knurre, you're
lying to the function.
Then call it for what it is "the __knurre calling convention, which
works for the knurre variadic function",
That function is declared as __stdcall. So it's stdcall calling
convention.
You must mean those 4 distinct functions declarations? No. What's
declared there as __stdcall is just a hack on the caller side to fool
the compiler into issuing bogus calls to what's eventually resolved as
the entry point address of your knurre function.
Don't know how you manage to write so much wrong.
Perhaps you're trying to goad me even further than you've managed so far.
Whatever.
The calls are not bogus: they're real, and they work. The compiler is not
fooled, it's told the truth, and that's why the calls work. The calls are not
"eventually" resolved, they're directly resolved, there's no indirection.
So.
the technique is not fragile, on the contrary it provides (when
implemented by a compiler)
...
Without tool support it is more fragile than a technique with tool
support.
...
it's trivial to implement a compliant __stdcall printf using that
technique if you have tool support (the compiler passes the number of
bytes). If you don't have tool support it is of course difficult.
Do you really not see all the when's and if's and could's in what you
wrote above,
I /wrote/ the 'if's, and there are no 'could's.
or do you just deliberately choose to ignore the obvious?
Apparently you think something is obvious. Given the quality of your reasoning
(so far non-existent) it's impossible to guess. What is it?
In case you lost sight of where this started, discussion was about
__stdcall, which has been established last millennium.
I think that's correct. Checking title of this thread... "calling convention
stdcall and cdecl call", yes, it seems you have grasped at least roughly what
it's about.
Whatever you digress now about possible future calling conventions,
You're trying to lie again. Don't. Just, every time you get the urge to lie, the
urge to deceive, then smoke a cigarette, take five push-ups, whatever.
For the record, I'm not digressing and have not been digressing.
All I've done has been to respond to your (less than grokkable) responses to me.
however clever or
exciting (not saying that's the case), but has no relevance whatsoever
to the topics of existing __stdcall.
Say that Igor, who started this sub-thread about what stdcall can and can't (or,
if you have trouble parsing that, read "could" or "couldn't").
I'm on record in this thread as agreeing with what you write here.
But now, simply by putting that forth as your own idea, which I don't doubt it
is!, you're making me suspect that I might have reached the wrong conclusion --
because the probability that you should write something meaningful is ~0.
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?