Thread: Stack push order for function arguments

Originally Posted by Mario F.

I'm just curious as to why arguments are pushed this way and if I can expect this to be standard behavior across compliant compilers.

They are pushed right to left so that the leftmost argument is always at the top of the stack in the called function's frame. This is to allow C-style variadic functions like printf() to work properly.

You can count on it working that way, unless you use some compiler feature to change things.

And since we are on the subject, probably a silly question... If this is indeed standard behavior doesn't this mean order of argument initialization is fixed and thus a language feature that allowed default values to evaluate formal arguments would be possible?

Just because the arguments are PUSHED in that order doesn't mean they must be EVALUATED in that order. You can't assume anything about the order of evaluation.

Indeed, as brewbuck says, it doesn't say anything about ORDER of evaluation, only about the order the arguments are pushed.

I used a peice of code similar to this:

Code:

    func1(func2(), func3());

I expected func3() and func2() to be called "in order", which worked fine on the first compiler I used (gcc on sparc), but when I later tried the same project on x86, it failed - func2 and func3 both have side-effects, and when they are called in the wrong order, things don't work right. So I ended up calling them explicitly, with temp variables to pass to func1().

--
Mats

Originally Posted by MacGyver

With the different calling conventions, there are multiple ways of passing variables around. This is just the standard one with C/C++.

True, x86-64 for example passes up to 6 args in registers, rather than on the stack - these six are of course selected "left to right".

--
Mats

afaik, you can't rely on the calling convention. If you want a particular convention, you'll have to use a compiler-dependent option, like __cdcel or __stdcall or whatever it's called.

Originally Posted by robwhit

afaik, you can't rely on the calling convention.

I don't have the spec with me now, but I'm reasonably sure it does say that a conforming implementation pushes right to left. It might even specify that the caller saves, but I'm not as certain about that one.

Originally Posted by Mario F.

A quick experiment revealed function arguments to be pushed onto the stack from "right to left".

[...]

I'm just curious as to why arguments are pushed this way and if I can expect this to be standard behavior across compliant compilers

For what little it is worth, early C compilers used YACC to do the parsing. It was convenient to make the rules left recursive, which meant the arguments were collected from right to left. This trickled down to low-level code generation. The original C++ compiler (known as "cfront") just used C macros to add the C++ features to C. So the mechanism became a de facto behavior, but not de jure standard.

Then it was standardized because it meant nobody had to change their compilers...

For Win32: http://www.unixwiz.net/techtips/win32-callconv.html

There used to be the _PASCAL_ calling convention but I believe that was only for 16-bit applications. Most of the Windows API used this convention at one time.

The only time the order ever mattered to me is when I was mixing assembly language with C. I had to know in what order the parameters were pushed onto the stack in order to use them correctly.

Originally Posted by Mario F.

Say, a = 2+5 and b = 2+5. If b is pushed before a, doesn't b need to be evaluated before a? If a were to be evaluated first, where would the result of the evaluation go while it waits for b to be pushed?

Some temporary location.

Code:

tmp1 = eval(a)
tmp2 = eval(b)

push tmp2
push tmp1

In practice the arguments are usually evaluated in the order they are pushed. But there are legitimate reasons to do otherwise.