Is it safe to pass "too many" arguments to a external function?

This situation can only occur without name mangling (I believe), so the below code is C. Say there is a function A defined in A.c as

void A(int x, int y){
    //Do stuff
}

Now there is also a separate file B.c:

extern "C"{
    void A(int x, int y, int z);
}

void B(){
    A(1, 2, 3);
}

A is initially declared to have only 2 arguments yet when declared in B.c it has an extra one, and it is called with that third in B(). I know it is possible to make this situation occur, for example when linking with fortran subroutines, OR when dynamically linking.

I imagine it is unsafe to pass an extra argument开发者_运维问答 to a function, can anyone explain what is happening in memory when a function is called and arguments are passed to it? And, therefore, how safe it is to pass this "extra" argument that is neither used nor wanted.

Is it possible that the extra argument overwrites a space in memory that is used within the function? Or does the function call to A allocate space in memory for the arguments then tell A where the beginning of the argument memory block is, A reads out the first two arguments and ignores the last, making it completely safe?

Any information on the function would be greatly enlightening, thanks.

Linkage is implementation-defined, so there is no way to say definitely.

That said, other features of C (notably vardic parameters) force an implementation that would usually allow it.

For example, I don't know of any implementation that would fail if you wrote:

 printf("%d", 1, 2);

It would, however, merely print "1".

Many people here are bringing up cdecl, pascal and __stdcall calling conventions. However, none of those are part of the Standard and are all features of certain implementions,. which bring us back to my first sentence.

It depends on the calling convention used. With cdecl, the caller pushes arguments onto the stack in right-to-left order, and then the callee accesses them by offsetting the stack pointer. Calling too many arguments won't break anything in this case.

If, however, you have a calling convention that is left-to-right, then things would break.

With the cdecl calling convention, the caller is responsible for cleaning up the stack, so this would be safe. To contrast, the pascal calling convention makes the callee responsible for cleanup, and so this would be dangerous.

In C this is a violation of constraints, therefore it results in undefined behaviour.

"If the expression that denotes the called function has a type that includes a prototype, the number of arguments shall agree with the number of parameters." (C99, §6.5.2.2)

That said, in practice it will depend mostly on the underlying calling conventions.

At least in C and C++ it won't do any harm. Arguments are pushed right to left and a callee is responsible for the stack cleanup.

However, the compiler won't let you do this unless you are using variadic parameters or cast a function type. For example:

#include <stdio.h>

static void foo (int a, int b, int c, int d, int e, int f, int g)
{
    printf ("A:%d B:%d C:%d D:%d E:%d F:%d G:%d \n",
            a, b, c, d, e, f, g);
}

int main ()
{
    typedef void (*bad_foo) (int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int);
    foo (1, 2, 3, 4, 5, 6, 7);
    bad_foo f = (bad_foo) (&foo);
    f (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17);
}

If you look at assembly code, all parameters are pushed into register but extra onces are just getting ignored.

Such code violates the One Definition Rule (well, C's equivalent of it anyway...) Whether it works or not is entirely platform specific.

Specifically on x86, if the function was declared __cdecl, then it would work, because the caller cleans the stack, but if it was __stdcall (as most Win32 functions are), the callee cleans the stack, and would clean it wrong in that case (because it got too many parameters). Therefore it would depend on that external function's calling convention used.

I can't understand why you'd ever want to do this though.

If I get it right, this might lead to your program to execude random code from memory. When a function is called, a few values, including the return address (where the program will jump back to when the function is finished) are pushed to the stack. After that, the function arguments (x, y, z) are pushed to the stack and the program jumps to the entry point of the function. The function will then pop the arguments (x, y) from the stack, do something, then pop the return address from the stack (z in this case, which is wrong) and jump back to it.

Here's a nice description of the stack details: http://www.tenouk.com/Bufferoverflowc/Bufferoverflow2a.html