Re: calling convention stdcalll and cdecl call
* Liviu:
"Alf P. Steinbach" <alfps@start.no> wrote
* Liviu:
"Alf P. Steinbach" <alfps@start.no> wrote
* Liviu:
"Alf P. Steinbach" <alfps@start.no> wrote
* Liviu:
"Alf P. Steinbach" <alfps@start.no> wrote
* Liviu:
"/before/" or not is meaningless here. The given code is generic, and
works for any stdcall or cdecl functions, present or future.
You've demonstrated that your code does not work generically for all
stdcall functions, as I understand the term
That's your problem right there ;-)
-- because it mangles register values willy-nilly. ;-)
For registers not marked as reserved for use by stdcall.
Why the heck would you reserve the EXX (any E...) register in
general?
Umm... That's straight from your "for example in a register" answer
to the question of how variadic functions would receive the number of
actual arguments. Seems quite obvious that you cannot use a register
unless you somehow reserve it, so that related code knows that it's
off limits to them.
If you choose to use a register for passing the size info to variadic
routines, all that's needed is to document that for this language
implementation, a stdcall variadic routine uses this register, say,
ESI; you don't need to reserve the register in general.
You miss the point, or feigning to. Point is that whatever register you
think you found which is not used by stdcall, and so decided to
appropriate it for "variadic stdcall", someone equally bright might have
found it longtime ago, and be already using the same register for
different purposes _within_ the specs of stdcall. Stealing the register
now for "variadic stdcall" would break the other person's old code at
the binary level. Thus, again, (stdcall + ESI) != stdcall.
Repeat some 667 times: it's impossible to break that code (in the way you suggest).
Anyways, as noted quite a few times already, why not pass on the stack if you're
afraid of that.
Practical technical solutions to irrational fears.
Say, as an example, that you used ESI to pass the size info in bytes of
all variadic "..." arguments pushed onto the stack. Then say that I am
proposing a similar, just slightly different, variadic convention using
ESI to pass the size info in DWORDs. By your argument, we would both
have the right to claim that what we have is "stdcall"
Yep.
- though it's
clear the two conventions are not binary compatible.
Yep. Generally, stdcall code generated by different tools for same source code
is not binary compatible. It is not a problem.
Yet, for some
reason, you insist that yours and yours only be called stdcall.
That is at best a misconception on your part.
You might try to find some quote to back it up (you won't find any).
That's exactly
what would make the "new stdcall" not binary compatible with stdcall.
It is possible but only barely possible that you think that two source
code identical routines compiled as __stdcall with different compilers
or compiler option sets must be binary compatible.
Yes, they should be able to call each other at the machine code level.
That's exactly what a calling convention like stdcall exists for. How
else do you think mixed language programming (let alone mixed compiler)
could possibly work?
That's not the case with g++ and msvc, which are the main ones I use,
Compile "int __stdcall foo(int bar) { return bar + 1; } with both and
compare the assembly listings. Look quite similar, don't they?
The fact that you can make some code that does not work in some respect (here
for illustrating difference in generated code) does not, at the technical level,
mean anything more than that you can make code that does not work.
I suggest you look at the examples given else-thread.
I know / read that there are issues due to function name decoration and
linker technicalities. None of which has anything to do with stdcall per
se, however. And even those issues must not be insurmontable, since
mingw seems to be happily using msvcrt.
You mean surmountable. Yes, there are levels of compatibility. And "stdcall"
does in practice have slightly different meanings in different contexts. The
compatibility you've noted is due to a restriction to arguments where the result
is roughly documented and in-practice well-defined regardless of tools.
Please repeat some 580 times or so: it's impossible to break binary
compatibility with code that does not yet exist.
Wow. If the windows developers reasoned the same (wrong) way, we'd all
be in big trouble by now ;-) After all, what they do all the time is
write code bound by published specs which insure binary compatibility
with future yet-to-be-written applications.
Yes and no. In some cases binary compatiblity is important and well-defined, as
with the use of [msvcrt.dll] that you noted above, and for that matter for any
use of Windows API functions. In other cases, and due to the nature of
programming that's most cases, where the code uses programmer-defined stuff,
that compatibility is not so important and generally not well-defined.
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?