views:

130

answers:

7

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.

A: 

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.

Billy ONeal
I think you mean "if it was `__stdcall` (as most win32 functions are), the **callee** cleans the stack".
Al
With `__stdcall`, did you mean the 'callee' or 'called function'? It currently says 'caller' again.
Jonathan Leffler
@Al + @Jonathan: Thanks guys. Fixed. Must curse all brain farts down to ...
Billy ONeal
+3  A: 

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.

Oli Charlesworth
Actually the key here isn't just that `cdecl` pushes left to right, its also that `cdecl` means the function responsible for cleaning the arguments off the stack is the same one that pushed them. `stdcall` on the other hand pushes arguments in the same order but relies on the called function to clean the stack, which would currupt the stack.
torak
@torak: Understood. But if there were a calling convention that did left-to-right (I can't think of an example, though), the callee would see nonsense arguments. So things would break in a different way.
Oli Charlesworth
For a list of x86 calling conventions see http://en.wikipedia.org/wiki/X86_calling_conventions. The `pascal` convention is one that pushes from left to right.
torak
+3  A: 

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.

Ignacio Vazquez-Abrams
+1 -- note that `__stdcall` also requires the callee to clean the stack. Note also that calling conventions are entirely platform specific and the standard says absolutely nothing about them.
Billy ONeal
-1 for answer based on implementation details and ignoring what the language standard says.
R..
A: 

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

jkramer
That's not the case with the default (`__cdecl`) calling convention.
Billy ONeal
+3  A: 

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.

James Curran
+1 to compensate for all the other upvoted crappy answers.
R..
The existence of varadic functions doesn't actually force the compiler to use a particular calling convention for non-variadic functions. In fact, this is *exactly* why variadic functions must be called with a correct prototype in scope - to allow the compiler to use a special calling convention.
caf
A: 

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.

Vlad Lazarenko
+1  A: 

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.

Alek