DEV Community

Cover image for Stack, Heap and How Function Calls Really Work
Pierre Kitz
Pierre Kitz

Posted on

Stack, Heap and How Function Calls Really Work

Most programmers hear about stack and heap memory, but many don’t really get what that means until a bug bites them hard. Especially in languages like C or C++, where you are the garbage collector—understanding memory matters. A lot.

The Memory Map You Should Know

When you run a C program, memory is usually split into these segments:

  • Code: Holds compiled instructions, i.e. your program translated to machine language.
  • Initialized Data: Some constants and literals, global variables and variables marked static inside functions.
  • Uninitialized Data: Reserved space for uninitialized global variables. This is often called 'Block Started by Symbol' (BSS), named after an old computer instruction.
  • Heap: An unordered lot of memory that is organized by the programmer using new or malloc.
  • Stack: An automatically neatly stacked pile of memory used for function calls. It holds function arguments, local variables and bookkeeping information.

Memory Segments

What Happens on a Function Call?

Let's take a simple function:

int increment(int x) {
    int result = x + 1;
    return result;
}
Enter fullscreen mode Exit fullscreen mode

When increment(3) is called:

  • The return address is pushed to the stack (so the program knows where to come back).
  • A stack frame is created with:
    • The argument x
    • The local variable result

Stack Example

  • When the function returns, its stack frame is 'popped', and that memory is officially gone.
  • However, in practice its still there but available to be overwritten as soon as another function is called. This is what can make this problem so mysterious.

So local variables exist only as long as the function runs. They live on the stack. And that is where people run into problems.

Why This Matters – A Classic Mistake

char* create_message() {
    char result[] = "Hello!";
    return result;
}

void print_date() {
  // ...
}

int main() {
  char* message = create_message();
  print_date();
  printf("%s\n", message);
}
Enter fullscreen mode Exit fullscreen mode

The local variable result lives on the stack. When create_message() returns, the stack frame is done. Now a pointer is returned to memory that will be used by the next function call. This is undefined behavior in C. A polite way of saying "good luck".

Stack Evolution

After calling print_date the value created in create_message() is likely overwritten by something else, often not even with the correct data type.

Want to keep the result alive?

Use the heap instead

char* create_message() {
    char* result = malloc(7); // allocate memory on the heap
    strncpy(result, "Hello!", 7);
    return result;
}

void print_date() {
  // ...
}

int main() {
  char* message = create_message();
  print_date();
  printf("%s\n", message);
  free(message); // deallocate memory on the heap
}
Enter fullscreen mode Exit fullscreen mode

Using the Heap

Now the content of the message is created on the heap where it will continue to exist until it is free()ed, independent of any function calls or stack manipulations.

Takeaways

  • Stack memory is fast and automatically managed, but short-lived.
  • Heap memory is manually managed and persistent across function calls but easy to leak.
  • In non-garbage-collected languages, forgetting this distinction leads to real bugs: use-after-free, memory leaks, dangling pointers.

This kind of foundational understanding unlocks many mysteries in C, C++, Rust, and even explains why some things behave weirdly in Java or Python.

Contact

I am a university lecturer who enjoys helping developers understand how things work under the hood. If you are learning programming or struggling with C or C++, transitioning from Java, or just want to chat about memory, debugging, or low-level programming, feel free to reach out. You can contact via <my username>@mailbox.org, or leave a comment below. I am happy to offer friendly advice or tutoring. If you are looking for 1:1 help or tutoring on C/C++, systems programming, or debugging, I'm exploring offering support sessions. Reach out and we can see what works.

Top comments (1)

Collapse
 
pgradot profile image
Pierre Gradot

While your explanation about heap and stack seems pretty solid, I think you missed an important aspect of function calls/returns: registers.

It almost certain that a function like increment() will not use the stack for its parameter and returned value (as soon as an option like -O1 is used, and nobody uses -O0 except for debugging).

I know it took me a while to discover the concept of registers. And it really changed the way I look at code and what it really does under the hood.