By the end of this lesson, cadets will be able to:
malloc and free. (Outcome 2)NULL. (Outcome 3)Complete before class. Beej Chapter 12 is the spine of today's lecture.
| Source | Sections | Why |
|---|---|---|
| Beej-C | Chapter 12 (Manual Memory Allocation) | malloc, calloc, free, the NULL check pattern |
| King, C Programming: A Modern Approach | Chapter 17 (Advanced Uses of Pointers) | Optional deeper dive into heap allocation patterns |
malloc, calloc, free, NULLToday is the last new content lesson before GR2. You learn how to ask the operating system for memory yourself, why every allocation must be matched by exactly one free, and how to keep track of who owns what so you do not leak memory, free the same block twice, or read freed memory.
The Lesson 15 deck covers stack vs heap, the four allocation functions from the standard library, the ask/check/use/return pattern, the decision table for choosing between stack and heap, and the ownership reasoning framework you will apply in the lab.
Every C program uses two regions of memory. The stack is managed by the compiler: every function call gets a frame, and that frame disappears when the function returns. Local variables live there. The heap is managed by you: you call malloc to ask the operating system for memory, the OS gives you a pointer, and the block stays valid until you call free.
The heap is not slower or worse than the stack; it is different. Each region has its own rules and its own use cases. Most programs use both.
You will write this pattern hundreds of times in the rest of the course. Four steps: ask, check, use, return.
The NULL check is not optional. malloc returns NULL when allocation fails; if you skip the check and try to dereference, your program crashes. Setting the pointer to NULL after free is a defensive habit; if any later code accidentally uses the pointer, the segfault is loud and immediate instead of quiet and corrupting.
Two questions usually decide for you.
| Question | Stack | Heap |
|---|---|---|
| Is the size known at compile time? | Yes | No or maybe |
| Does the data outlive the function? | No | Yes |
| Is the data small? | Yes (a few KB) | Any size |
| Do I want to manage it myself? | No | Yes |
For every malloc your program does, answer these three questions out loud (or in a comment):
The four ownership markers from the slide deck name the answers in code:
| Marker | Where it goes |
|---|---|
| // owns: | above a function that returns heap memory |
| // borrows: | above a function that takes a pointer but does not free |
| // alloc owner: | next to every malloc/calloc call |
| // free owner: | next to every free call |
You will apply these markers in Part B of today's lab.
Today's lesson introduces §8.5 of the DFCS C Programming Standard: always free dynamically allocated memory. The ownership annotation convention you use in Part B is one practical way to follow this rule: if every allocation has a named owner and every owner has a corresponding free, you do not leak. See the Resources section for the full standard. Lesson 19 will revisit §8.5 when struct members are themselves heap pointers.
Two things to do in class. Use the checklist to track your progress.
make_play_counts and tally_plays and write your own tests in test_lab15.c. Part B: add the four ownership markers to annotate1.c, annotate2.c, and annotate3.c. The full spec is in the repo README.
Twelve tasks across four sections. Type each C statement at the prompt. The terminal shows what memalloc did; the middle pane shows the current stack; the right pane shows the heap.
Enter your name. It will appear on the completion screen so you can include it in your screenshot for the Lesson 15 reflection.
enter_function name and leave_function to simulate scope changes. The task card tells you what to type next. Mistype twice and the hint button will pulse.