calling function with inadequate args (via function pointer)
Felix Kater
what does gcc do in case I call a function with not enough or too many
arguments like this:
int f(int i, int k){ /* ... */ return 0; }
int main(int argc, char** argv){
int(*g)(int,...);
g=((*)(int,...))f;
g(0); /* not enough arguments */
g(0,1,2); /* too many arguments */
return 0;
}
Besides the fact that the arguments inside f may not contain reliable
values: Is this code without any memory leaks or other danger?
Thank You
Felix
Paul Pluzhnikov
> what does gcc do in case I call a function with not enough or too many
> arguments like this:
It does exactly what you told it -- calls the functions with not
enough or too many args.
> int f(int i, int k){ /* ... */ return 0; }
> Besides the fact that the arguments inside f may not contain reliable
> values: Is this code without any memory leaks or other danger?
We can't tell: it depends on what "k" is used for ...
// no danger whatsoever
int f(int i, int k) { return i+k; }
// danger of starting 3rd world war due to uninitialized "k"
int f(int i, int k) { if (k) nuke_Korea(); return 0; }
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
Felix Kater
Paul Pluzhnikov <ppluzhn...@charter.net> wrote:
> // danger of starting 3rd world war due to uninitialized "k"
> int f(int i, int k) { if (k) nuke_Korea(); return 0; }
Ok, that's what I expected for not enough arguments.
However, what's with the second call of g where the function is called
with too many arguments? Will this cause errors on return of the
function (since 3 pushed to the stack and just 2 pop'ed or whatever) ?
Felix
Paul Pluzhnikov
> However, what's with the second call of g where the function is called
> with too many arguments? Will this cause errors on return of the
> function (since 3 pushed to the stack and just 2 pop'ed or whatever) ?
There are several popular calling conventions.
Many calling conventions (e.g. SPARC and x86_64) pass first N args
in registers. Obviously there is nothing to push and pop, so there
is no danger.
On x86 under Linux, the calling convention is that caller pushes
*and* pops, so there is no danger either.
On Win32/x86, there is "stdcall" calling convention where caller
pushes but callee pops. That convention can not work for functions
with variable number of args (callee has no idea how many to pop),
and you could get into trouble when you cast stdcall function
pointer to a "regular" function pointer.