Stack, Heap and How Function Calls Really Work

Pierre Kitz — Fri, 30 May 2025 22:00:00 +0000

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.

What Happens on a Function Call?

Let's take a simple function:

int increment(int x) {
    int result = x + 1;
    return result;
}

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

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);
}

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".

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
}

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.

Why You Do Not Love C or C++

Pierre Kitz — Thu, 29 May 2025 12:55:59 +0000

You might have dabbled in C or C++ before. It is versatile, ubiquitous and fast. But it can easily become fragile, cryptic and frustrating.

Have you been hit be one or more of the following:

cryptic compiler errors
mysterious segmentation faults
so called 'undefined behavior'

You are not alone.

C and C++ give you big power with minimal safety rails. And unless you understand what is going on under the hood, you are going to trip over things that feel invisible.

Common Mistakes That Burn Newcomers

Returning a pointer to a local variable
Forgetting to free allocated memory (or freeing it twice)
Accessing memory after it has been freed
Buffer overflows while using char*
Using new without delete, or mixing with malloc and free
Using int* as if it where a Java reference
Assuming arrays know their size (they do not)
Ignoring return values from malloc, fopen, etc.
Believing nullptr will save you

What If It Did Not Have to Be This Way?

What if you had:

A clear mental model of how memory really works
Some simple rules to avoid 80% of bugs
Tools that show you where your program is breaking
A way to write C/C++ that is not just fast—but simple and safe

Coming Soon: A Mini-Series for Beginners

Topics that are often glossed over when you need to learn a language quickly. Knowledge that is not only useful for C or C++ but will help make you a better programmer in many languages.

You will learn:

How the stack and heap really work
Why memory bugs happen (and how to catch them)
Tools like Valgrind and AddressSanitizer
How to write simpler, safer code using modern idioms

No heavy theory. Just practical examples and clear takeaways.

Stay tuned!

DEV Community: Pierre Kitz

Stack, Heap and How Function Calls Really Work

The Memory Map You Should Know

What Happens on a Function Call?

Why This Matters – A Classic Mistake

Want to keep the result alive?

Takeaways

Contact

Why You Do Not Love C or C++

Common Mistakes That Burn Newcomers

What If It Did Not Have to Be This Way?

Coming Soon: A Mini-Series for Beginners

Contact