Memory Layout Deep Dive

By the end of this lesson, cadets will be able to:

1. Identify the standard memory segments of a running C program: text, data, BSS, heap, and stack. (Outcome 2)
2. Predict which segment a given program element occupies, including globals, statics, locals, string literals, and dynamically allocated data. (Outcome 2)
3. Explain at a high level how virtual memory gives each process its own private address space on top of shared physical memory. (Outcome 2)

Complete before class. The instructor notes and diagram below are the primary reading; the optional source goes deeper.

Pre-Class Checklist

You have spent the semester declaring variables, calling functions, and allocating memory with malloc. Each of those things ends up in a specific region of memory, and the region is not arbitrary. Today you learn the map of a running C program and the two questions that decide where anything lives.

Slides

The Lesson 38 deck walks the memory map from top to bottom, places examples in each segment, and closes by looking ahead to your team presentations. The slides are the spine of the in-class lecture; the memory-map walkthrough is where you practice placing things yourself.

Open Lesson 38 slides → replace href with your SharePoint link

The map of a running program

When your program runs, the operating system gives it an address space: a range of memory addresses laid out from high to low. That space is divided into regions, each with its own job and its own rules. High addresses sit at the top; the lowest addresses at the bottom. This is the single picture to carry out of this lesson.

The five segments of a C process, with the stack and heap growing toward each other through the unused middle.

The five segments

Read the map from the bottom up, because that is roughly the order in which things are decided, from fixed-at-compile-time to decided-at-run-time.

The pointer trap. A line like animal_t *p = malloc(sizeof(animal_t)); creates two objects in two different segments. The pointer variable p lives on the stack; the block it points to lives on the heap. When the function returns, the stack reclaims p automatically, but the heap block stays allocated until you free it. Forgetting that is exactly the leak that valgrind reports.

Two questions decide everything

You do not need to memorize a table of cases. For any variable, two questions place it:

1. What is its scope and lifetime? A plain local inside a function goes on the stack. Anything at file scope, or marked static, lives for the whole run and goes in data or BSS. Anything from malloc goes on the heap.
2. Does it have an initializer? For whole-run variables, an initial value puts it in data; no initializer puts it in BSS.

Notice that scope, not syntax, decides the home. The exact same line int n = 5; goes on the stack inside a function and into the data segment at file scope. That is the single most useful idea in this lesson, and the walkthrough drills it directly.

Virtual memory, briefly

The address space in the diagram is virtual. Every running program sees the same clean layout starting from low addresses, as if it owned the whole machine. It does not. The operating system maps each program's virtual addresses onto whatever physical memory is actually free, and keeps each program's space private from the others.

Two practical consequences follow. First, the addresses you print are virtual, so the same program run twice can report different numbers (modern systems also randomize the layout on purpose for security). Second, one program cannot read or corrupt another's memory by accident, because they do not share an address space. You do not need the page-table details for this course. You need the mental model: each process gets its own private map, and the diagram is that map.

DFCS C Programming Standard

This lesson does not introduce a new style rule; it reinforces one you already follow. The heap discipline in §8.5 (every allocation has a matching free; no leaks) is exactly what the memory map makes concrete. The stack reclaims its frames for you, but the heap is yours to manage. The capstone lab is graded in part on a clean valgrind run, which is the standard's no-leak rule made measurable. The full standard lives in the course Resources section.

Two things to do in class. Use the checklist to track your progress.

• Work through the memory-map walkthrough below. Twelve guided tasks across four sections. Declare or allocate what each task asks for, predict the segment, then watch the map fill in. About 20 minutes.
• Start the capstone lab: Aspen Humane Society Roster. Your synthesis lab. Auto-graded through GitHub Classroom and Gradescope.
  This lab is due at Lesson 40, not next lesson. The extra time is on purpose: treat it as a real warmup for the final.
  Accept the capstone on GitHub Classroom →

Memory-Map Walkthrough

Twelve tasks across four sections. Each task names a scope (file scope, or inside main). Decide which segment the object lands in before you press Enter, then type the declaration and watch the right pane.

• Keep working the capstone lab. It is due at Lesson 40; get to a clean valgrind run before you submit.
• Complete the Lesson 38 reflection in Blackboard. Use your completion code from the walkthrough and attach your screenshot.
• Replay the walkthrough in free mode. Try your own declarations and allocations and predict the segment before you press Enter.
• Heads up: team PEX presentations are at Lesson 39, then review at Lesson 40 and the final at Lesson 41. The memory map is fair game on the final.