Function Call Stack Examples

The call stack is a dynamic entity: its contents and size change, growing as functions are called and shrinking as functions complete. This makes it a little difficult to explain with static text and pictures just as describing how a program which uses a loop can be difficult to describe due to the things changing in each iteration of a loop. This document makes a stab at showing stack behaviors but it will take some patient reading and analysis.

• ints are 4 bytes (32-bits) and doubles are 8 bytes (64-bits). This is the case on many modern platforms but may vary somewhat and is not guaranteed by the C standard.
• The starting address of the first stack frame is chosen arbitrarily. In most cases, it is not important where it starts, only to understand the mechanics of how it grows and shrinks.

Open up the source code associated with this document in a different program or browser window. View the stack behavior in the browser and follow along in source code as steps are taken.

Like all programs, control for the program starts in the main() function with the first line. main() has 3 local variables: a,y which are ints and x which is a double. The initial state of the stack is as follows.

Notice that at the beginning of running main (line 12), stack space is allocated for all of its local variables but none of them have defined values yet. C programs do not guarantee local variables are initialized to anything and it is a mistake to use a variable value without first ensuring it has a well-defined value.

After moving ahead one line in main, locals a,y have defined values. This probably constitutes several low-level machine/assembly instructions.

At line 13 a different function is invoked. Control is suspended in main until the function mogrify completes. Calling a function pushes another stack frame onto the call stack which has enough space for the arguments to the function any local variables as shown below.

Notice that the new stack frame starts almost immediately after the frame for main. There may be a small amount of additional space required to deal with return values or register saves at the low level, but in our high-level view this doesn't matter too much and we will always start the stack frames as close to each other as possible.

Notice also that the difference in the locations is 8 bytes: this is because the variable x in main is a double so takes 8 bytes of space whereas all the other variables seen so far take 4 bytes as they are integers.

Control now starts at the beginning of mogrify but will eventually return to main at which point it will resume execution on line 13 completing that line and moving forward.

Finally, notice that the parameters a,b to mogrify have values defined. This is as a result of main calling the function and passing actual values in for those parameters. The local variable tmp does not yet have known value associated with it as the first line of mogrify has not yet executed.

After executing one line of mogrify, the local variable tmp takes on a value due to its assignment. Make sure you understand the integer arithmetic behind this assignment (17 / 3 is 5 remainder 2 in integer division).

The second line of mogrify is to return a value to the calling function. This has two effects.

• The return value is stored wherever it was intended from the calling function: line 13 of main stores the value in variable mog.
• Returning pops the stack frame for mogrify off the call stack leaving it in the state above.

Control now resumes in main by advancing one line forward.

printf is like other functions in that it will push another stack frame onto the stack with space for its arguments and local variables. printf is a little unique in that it is a variadic function: it can take any number of arguments so long as the arguments coincide with the format string. Analyzing the code for printf is not pertinent to gaining a basic understanding of the function call stack so we'll presume printf does its business, puts something on the screen like

Done with mogrify

and returns which pops its stack frame. Control resumes in main at the next relevant line of code.

At line 16, another function is called which pushes another stack frame onto the call stack.

When truly_half is called, its stack frame is pushed on below main; notice that the memory addresses for its local variables are identical to previous function calls to mogrify and printf. Space on the stack is re-used by subsequent function calls. This has implications for the values of variables that are not assigned values which we may discuss later.

The first line of truly_half assigns tmp as follows.

Executing the next line of truly_half returns this value to assign the local variable x in main and pops the stack frame of truly_half off the call stack.

In main another result is printed

Done with truly_half

and control advances. Line 19 calls mogrify again with different arguments

Control in main is suspended at a different location than the first call to mogrify (line 19 this time) but control begins again in mogrify at its first line (line 4).

Notice that the first argument to mogrify in this call is a little interesting: it was passed as a double with value 8.5 but appears as an int with value 8. The compiler has automatically inserted low-level instructions to caste the 8-byte floating point value to a 4-byte integer value. Most of the time this is nice convenience which saves programmers the trouble of writing such code but it can create subtle bugs if the programmer did not intend for such a conversion to happen.

mogrify completes assigning its result to local variable a in main and popping its stack frame off.

The program completes by printing the final results

Results: 23 8.500000

and returning 0. Two things to note here:

• main is also a function which returns meaning its stack frame will be popped off and control will be returned to the mysterious and powerful C runtime system which is responsible for setting up main to run in the first place.
• The integer return value from main is passed back to whatever entity ran the program in the first place. Unix refers to this value as the exit status of a program. The unix convention is that a 0 exit status indicates everything went normally for the program while a non-zero return corresponds in some way to an error that occurred. Shell programs can access the return codes of programs to detect, for instance, that gcc did not succeed in compiling some code or that the search program grep did not find anything matching search terms.

This is a somewhat more involved example. The computation doesn't do anything particularly interesting but is a good demonstration of how the stack can grow and shrink as one function calls another function. Little explanation is given in each step so pay careful attention to which line is being executed and remember that after a return is executed, control returns to the previous function and a stack frame is popped off.

Two minor notes

• All of the variables in this example are double so are assumed to be 8 bytes which means the size of memory cells will differ by 8
• The stack starts at memory address 2048 this time. In examples it is fairly arbitrary where the frame for main starts in the stack but after specifying its location, the behavior of the program follows a well-defined patter.

Output

10.500

It is common to want to swap the values of two variables. Unfortunately, writing a function to carry out this task in the most obvious way proves fruitless. One can understand why the swap_ints() function above does not actually swap values using the call stack. C allocates new memory for the arguments to functions and the actual argument values are copied into this area. Thus arguments within the function are distinct from any variables that were used to call the function. Changes to function parameters do not affect any other variables.

As usual, execution starts in the main function.

Output

x=20  y=50

Note that the return type of swap_ints is void: it is not meant to return anything, only have side-effects by altering something about the program. This makes line 7

return;

perfectly valid. Unfortunately, the desired side-effect of swapping the variables x,y in main has not been achieved. On advancing to the next line and printing, the output clearly shows that x,y have retained their original values.

x=20  y=50

This is because during the execution of swap_ints, the function had its own copies of the values 20,50 which referred to with names a,b. These are distinct from the x,y in main and change independently. This the swapping done in swap_ints does not affect any values in main.

It is not possible to use a simple function definition to get variable swapping to work. This is due to the call-by-value semantics C uses for function invocation. Instead, one must resort to more complex means to get swapping to work. Two common options are employed: (1) use a preprocessor macro, or (2) use pointers and addresses.