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
staticinside 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
newormalloc. - 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
- The argument
- 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.