Memory layout — text, data, BSS, heap, stack segments: Exercises

Level 1 — Recognition

Here you only need to name the segment where a thing lives. No reasoning chains yet, just pattern-match against the definitions.

Worked example Exercise 1.1

For each declaration, name the segment. All are at file scope (outside any function).

int   a = 100;   // (i)
int   b = 0;     // (ii)
int   c;         // (iii)
const char *msg = "hello";   // (iv) where does msg live? where do the letters "hello" live?

Recall Solution 1.1

(i) a = 100 → Data. Global, initialized to a non-zero value, so the literal 100 must be stored on disk.
(ii) b = 0 → BSS. Global initialized to zero — no information to store, just "reserve 4 bytes, fill with 0."
(iii) c → BSS. Global uninitialized is treated as zero by the C standard.
(iv) The pointer msg is initialized to a non-zero address, so msg itself lives in Data. The characters "hello" are a string literal → they live in the Text (read-only) segment (or a read-only data area that is part of the read-only image). You may not write to them.

Recall Solution 1.2

(a) heap top ↔ (2) program break. Calling malloc may move the break upward (higher address).
(b) stack top ↔ (1) rsp. Pushing a frame decreases rsp (stack grows down).

Level 2 — Application

Now you combine rules: static, function scope, and pointers-vs-pointees.

Worked example Exercise 2.1

Classify each labelled item.

#include <stdlib.h>
int total = 12;                 // (A)
void tick(void) {
    static int count = 0;       // (B)
    static int limit = 60;      // (C)
    int tmp;                    // (D)
    char *buf = malloc(256);    // (E) buf?  *buf (the 256 bytes)?
}

Recall Solution 2.1

(A) total = 12 → Data. Global, non-zero initialized.
(B) count = 0 → BSS. static gives it static storage duration (it survives between calls), and it is zero → BSS.
(C) limit = 60 → Data. static, non-zero initializer → the 60 must be stored.
(D) tmp → Stack. Plain local (automatic) variable inside tick's frame; born on entry, gone on return.
(E) buf (the pointer) → Stack (it is a local automatic variable). The 256 bytes it points to → Heap, returned by malloc, and they outlive the function until you free them.

Recall Solution 2.2

True. Both have static storage duration — they exist for the whole program run. static inside a function only hides the name; the lifetime is the same as a global.
False. Globals live in BSS and are guaranteed zero by the C standard, so g == 0.
True. Locals live on the stack, which is not zeroed; the bytes hold whatever was there before → undefined value.

Level 3 — Analysis

Now you reason about addresses and file sizes, not just names.

Worked example Exercise 3.1

A program prints the addresses of one heap block and one stack local (hex, one machine):

heap  block p = 0x0000561f2a3b6260
stack local a = 0x00007ffe1c4d9abc

(i) Which number is bigger, and does that match the layout? (ii) A second malloc returns 0x0000561f2a3b62a0. Did the heap grow up or down here? (iii) A deeper nested call declares a new local b at 0x00007ffe1c4d9a9c. Did the stack grow up or down?

Recall Solution 3.1

(i) Stack address 0x7ffe... is much larger than heap 0x561f.... This matches the layout: heap sits low, stack sits high, with a big empty gap between them.
(ii) Second block ...62a0 is larger than the first ...6260 (difference 0x40 = 64 bytes). The address increased, so the heap grew up (toward higher addresses), as expected.
(iii) New local b at ...9a9c is smaller than a at ...9abc (difference 0x20 = 32 bytes lower). Address decreased, so the stack grew down as we descended into a deeper call. ✔ consistent with the layout formula.

Worked example Exercise 3.2

Two versions of the same file are compiled; size a.out reports the section byte counts:

version	text	data	bss
A: `int arr[1000000] = {1};`	2000	4000032	8
B: `int arr[1000000];`	2000	32	4000008

(i) Explain the numbers. (ii) Which executable file is bigger, and by roughly how much? (iii) Which uses more RAM at runtime?

Recall Solution 3.2

(i) In A the array is initialized (even one element), so the whole 1,000,000 × 4 bytes ≈ 4,000,000 bytes of literal values must be stored on disk → they land in data. In B the array is all zeros → it goes to bss, which stores only a size record, so data stays tiny and bss swells by ~4 MB.
(ii) The file carries text + data on disk (bss is just a number, not real bytes on disk). So A is larger. Difference ≈ 4000032 - 32 = 4{,}000{,}000 bytes ≈ 4 MB bigger.
(iii) The same. At load time the OS reserves and zero-fills the bss region in RAM, so both programs hold a 4 MB array in memory while running. The only difference is disk size.

Level 4 — Synthesis

Now you combine multiple segments and lifetimes into one judgement.

Worked example Exercise 4.1

Spot the bug and name the segment involved.

char *make_greeting(void) {
    char buf[16];
    strcpy(buf, "hi");
    return buf;          // <-- ?
}

(i) What is wrong? (ii) Which segment is buf in, and what happens to it on return? (iii) Rewrite it two correct ways: one heap-based, one caller-buffer-based.

Recall Solution 4.1

(i) make_greeting returns a pointer to buf, a local. After return, that stack frame is gone. The caller holds a dangling pointer to memory that will be reused by the next call — undefined behaviour. See Pointers and dangling pointers.
(ii) buf is on the Stack (automatic array in the function's frame). On return the stack pointer moves back and the 16 bytes are considered free; any later function call overwrites them.

(iii) Two fixes:

/* Fix A: put it on the heap, caller frees */
char *make_greeting(void) {
    char *buf = malloc(16);   // heap: outlives the function
    if (buf) strcpy(buf, "hi");
    return buf;               // caller must free()
}
/* Fix B: caller supplies the buffer, no ownership question */
void make_greeting(char *out, size_t n) {
    strncpy(out, "hi", n);
}

In Fix A the block lives on the Heap and survives return (see malloc, calloc, realloc and free). In Fix B the storage is the caller's — could be their stack or heap — and the callee just writes into it.

Recall Solution 4.1

(i) Program 1 → heap exhaustion (malloc eventually returns NULL). Program 2 → stack overflow (rsp is pushed past its limit).
(ii) Program 1 exhausts the Heap (break keeps climbing). Program 2 exhausts the Stack (frames keep pushing downward). Related: Buffer overflow and stack smashing and Stack frames and the calling convention.
(iii) Heap grows up from the low side, stack grows down from the high side, and they eat into the same middle gap. If the heap climbs high enough or the stack sinks low enough, they meet — but each hits its own guard/limit first, so you get two different named crashes even though they compete for one region of address space. See Virtual memory and paging for how that gap is mapped.

Level 5 — Mastery

Full multi-part reasoning that ties segments, disk, RAM, and lifetime together.

Worked example Exercise 5.1

A 64-bit program has these globals and a main:

int    table[500000] = {7};   // (P)
int    scratch[500000];       // (Q)
char   name[] = "grid";       // (R)
int main(void) {
    static double cache[100000];      // (S)
    int  n = 5;                       // (T)
    int *heapbuf = malloc(500000*4);  // (U) the pointer, and the block
    ...
}

(i) Put every labelled item in its segment. (ii) Estimate the on-disk contribution of P vs Q vs S (int = 4 bytes, double = 8 bytes). (iii) Estimate runtime RAM used by P, Q, S, and the U-block. (iv) If we deleted the = {7} from P (making it all-zero), which column of size would shrink and by how much?

Recall Solution 5.1

(i) Segments:

P table = {7} → Data (initialized, non-zero element).
Q scratch → BSS (global, uninitialized/zero).
R name[] = "grid" → this is a writable char array initialized from a literal, so the array itself lives in Data (5 bytes: g r i d \0). (The literal it copies from is read-only, but the array is a mutable Data object.)
S static double cache[100000] → BSS (static storage, zero-initialized).
T n = 5 → Stack (automatic local).
U heapbuf pointer → Stack; the 500000*4 block → Heap.

(ii) On-disk contribution:

P: initialized array of 500000 × 4 = 2{,}000{,}000 bytes → ≈ 2 MB in Data on disk.
Q: all zero → BSS → ≈ 0 on disk (just a size record).
S: zero → BSS → ≈ 0 on disk.

(iii) Runtime RAM (all reserved and, for BSS, zero-filled):

P: 2{,}000{,}000 bytes = 2 MB.
Q: 2{,}000{,}000 bytes = 2 MB (BSS still takes real RAM at runtime).
S: 100000 × 8 = 800{,}000 bytes = 0.8 MB.
U-block: 500000 × 4 = 2{,}000{,}000 bytes = 2 MB on the heap.
So even though Q and S cost ~0 on disk, together they cost 2.8 MB of RAM at runtime.

(iv) Removing = {7} makes table all-zero, so it migrates Data → BSS. The data column of size shrinks by its 2{,}000{,}000 bytes, and bss grows by the same amount. Net: the file on disk shrinks by ≈ 2 MB; runtime RAM is unchanged.

Worked example Exercise 5.2

Rank these four by on-disk cost (largest first), assuming all are file-scope globals on a 64-bit box:

(1) long big[262144] = {1};   // long = 8 bytes
(2) long zeros[262144];
(3) char *p = "text";
(4) int  small = 42;

Recall Solution 5.2

Compute each item's disk footprint:

(1) initialized long array → Data, 262144 × 8 = 2{,}097{,}152 bytes ≈ 2 MB on disk. Largest.
(4) int small = 42 → Data, 4 bytes.
(3) char *p → Data pointer = 8 bytes (the 4-byte-ish literal "text" sits in read-only text, counted separately/tiny).
(2) all-zero long array → BSS, ≈ 0 bytes on disk (size record only). Smallest.

Order (largest → smallest on disk): (1) > (3) > (4) > (2). ( (3)'s pointer is 8 bytes vs (4)'s 4 bytes, so the pointer edges out the int.)

Connections

malloc, calloc, realloc and free — the heap-side of every *p block above.
Stack frames and the calling convention — why locals vanish on return (Ex 4.1).
Static and global variables — storage duration — the Data-vs-BSS rule that drives L1–L2.
Pointers and dangling pointers — the returned-buf bug in Ex 4.1.
Virtual memory and paging — the shared middle gap in Ex 4.2.
Buffer overflow and stack smashing — the danger end of the stack.