1. c_proc/func() bug ?
I was playing around with the new ability to use define_c_proc/func and
c_proc/func with machine code functions. What puzzled me a bit was the order
in which arguments are pushed.
Assume the following:
foo = define_c_func("", function_pointer, {C_INT,C_INT,C_INT}, C_INT)
result = c_func(foo, {1, 2, 3})
Since this uses stdcall, the stack should look like this when the function
is called:
esp+0: return address
esp+4: 3
esp+8: 2
esp+12: 1
But what i got was this:
esp+0: return address
esp+4: 1
esp+8: 2
esp+12: 3
What gives?
2. Re: c_proc/func() bug ?
mic _ wrote:
> I was playing around with the new ability to use define_c_proc/func and
> c_proc/func with machine code functions. What puzzled me a bit was the
> order in which arguments are pushed.
>
> Assume the following:
>
> foo = define_c_func("", function_pointer, {C_INT,C_INT,C_INT}, C_INT)
> result = c_func(foo, {1, 2, 3})
>
> Since this uses stdcall, the stack should look like this when the
> function is called:
>
> esp+0: return address
> esp+4: 3
> esp+8: 2
> esp+12: 1
>
> But what i got was this:
>
> esp+0: return address
> esp+4: 1
> esp+8: 2
> esp+12: 3
>
> What gives?
In both __cdecl and __stdcall the arguments are
pushed in reverse order, i.e. the last argument
is pushed first.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: c_proc/func() bug ?
Mic:
This is from MSDN:
Microsoft Specific =97>
-----------------------------------------------------------------------
The __stdcall calling convention is used to call Win32 API functions. The
callee cleans the stack, so the compiler makes vararg functions __cdecl.
Functions that use this calling convention require a function prototype.
The following list shows the implementation of this calling convention.
Element Implementation=20
Argument-passing order Right to left.=20
Argument-passing convention By value, unless a pointer or reference type is=
passed.=20
Stack-maintenance responsibility Called function pops its own arguments
from the stack.=20
Name-decoration convention An underscore (_) is prefixed to the name. The
name is followed by the at sign (@) followed by the number of bytes (in
decimal) in the argument list. Therefore, the function declared as int
func( int a, double b ) is decorated as follows: _func@12=20
Case-translation convention None=20
-----------------------------------------------------------------------
This is the default calling convention for C and C++ programs. Because the
stack is cleaned up by the caller, it can do vararg functions. The __cdecl
calling convention creates larger executables than __stdcall, because it
requires each function call to include stack cleanup code. The following
list shows the implementation of this calling convention.
Element Implementation=20
Argument-passing order Right to left=20
Stack-maintenance responsibility Calling function pops the arguments from
the stack=20
Name-decoration convention Underscore character (_) is prefixed to names=
=20
Case-translation convention No case translation performed=20
Bernie
4. Re: c_proc/func() bug ?
Yeah I can see now it was correct. I just remembered something was supposed
to be reversed. It's been too long since I messed around with those kinda
things..
What's weird though, is that my program didn't crash when i had forgot do
"ret 12" instead of just "ret" which i had put at first. Maybe that was just
"luck".
5. Re: c_proc/func() bug ?
----- Original Message -----
From: "mic _" <stabmaster_ at hotmail.com>
To: <EUforum at topica.com>
Subject: c_proc/func() bug ?
>
>
> I was playing around with the new ability to use define_c_proc/func and
> c_proc/func with machine code functions. What puzzled me a bit was the
order
> in which arguments are pushed.
>
> Assume the following:
>
> foo = define_c_func("", function_pointer, {C_INT,C_INT,C_INT}, C_INT)
> result = c_func(foo, {1, 2, 3})
>
> Since this uses stdcall, the stack should look like this when the function
> is called:
>
> esp+0: return address
> esp+4: 3
> esp+8: 2
> esp+12: 1
>
> But what i got was this:
>
> esp+0: return address
> esp+4: 1
> esp+8: 2
> esp+12: 3
>
> What gives?
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
>
6. Re: c_proc/func() bug ?
>Yeah I can see now it was correct. I just remembered something was supposed
>to be reversed. It's been too long since I messed around with those kinda
>things..
>What's weird though, is that my program didn't crash when i had forgot do
>"ret 12" instead of just "ret" which i had put at first. Maybe that was just
>"luck".
Mic:
Pascal pushs stack left to right.
"C" pushs stack right to left.
The raeson "C" is right to left was because "C" added the
capability to use a variable number of arguments in a call.
Bernie
