String handling — char arrays, null terminator, strcpy, strcat, strlen, sprintf (dangers): Worked examples

The scenario matrix

Before any example, let us list every distinct situation a C string can be in. If a bug or a surprise exists, it lives in one of these rows.

Cell	Case class	What is special	Covered by
A	Normal string, room to spare	length + `'\0'` easily fits buffer	Ex 1
B	Buffer exactly full	`len + 1 == size` (the boundary)	Ex 2
C	Off-by-one overflow	`len + 1 > size` by exactly one byte	Ex 3
D	Empty / degenerate string	length $0$ , first byte is `'\0'`	Ex 4
E	Missing terminator	array has no `'\0'` at all → runaway scan	Ex 5
F	Concatenation overflow	`strlen(dst)+strlen(src)+1 > size`	Ex 6
G	Limiting / cost behaviour	repeated `strcat` → quadratic time	Ex 7
H	`sprintf` output longer than buffer	formatted text overflows silently	Ex 8
I	`sizeof` trap across a function boundary	`char *` param vs real array	Ex 9
J	Bounded `snprintf` truncation (the safe fix)	output too long but no overflow	Ex 10

Two colour conventions used in every figure below:

Cell A — normal string with room

Worked example Ex 1 ·

strlen and copy with a roomy buffer

char src[] = "dog";
char dst[8];
my_strcpy(dst, src);
printf("%zu\n", my_strlen(dst));

Forecast: How many bytes does src use? What does the printf print? Does dst overflow?

Figure — String handling — char arrays, null terminator, strcpy, strcat, strlen, sprintf (dangers)

Count src's bytes. "dog" is d o g '\0' = $4$ bytes. Why this step? Because the copy must move all bytes including the terminator — see the coral box in the figure.
Copy into dst[8]. We write $4$ bytes into an $8$ -byte array. $4 \leq 8$ , so no overflow. Why this step? Cell A is defined by "room to spare" — this is the safe baseline against which every later bug is measured.
my_strlen(dst) scans d(1) o(2) g(3) '\0'(stop) and returns $3$ . Why this step? Length counts characters before '\0', so the count is $3$ , not $4$ .

Recall Verify

Reveal ::: strlen("dog") == 3, copy needs $4$ bytes, $4 \leq 8$ ✓ no overflow.

Cell B — buffer exactly full (the boundary)

Add the terminator. "cat" = c a t '\0' = $4$ bytes. Why this step? Every string literal silently appends '\0' — you must budget for it.
Fit into a[4]. $4$ bytes into $4$ bytes: exactly full, len + 1 == size. Why this step? This is the boundary case — legal, but there is zero slack. One more character and we are in Cell C.
strlen(a) scans c(1) a(2) t(3) '\0' → returns $3$ .

Recall Verify

Reveal ::: strlen("cat") == 3 and $3 + 1 = 4 =$ buffer size (exact fit) ✓.

Cell C — off-by-one overflow

Count what must be written. "Hello" = H e l l o '\0' = $6$ bytes. Why this step? The five letters are visible; the sixth byte ('\0') is invisible but mandatory.
Compare to the buffer. $6 > 5$ . strcpy writes byte index $5$ past the array's last valid index $4$ . Why this step? Cell C is exactly len + 1 > size by one — the most common real bug in C.
What C does: nothing to stop you. The dashed coral box in the figure (the neighbour's byte) gets a $0$ written into it → buffer overflow, undefined behaviour. Why this step? There is no bounds check (Buffer Overflow & Memory Safety); the corruption may crash now, later, or be exploited.

Recall Verify

Reveal ::: needed bytes $= 5 + 1 = 6$ , buffer $= 5$ , overflow amount $= 6 - 5 = 1$ byte ✓.

Cell D — the empty / degenerate string

Layout of "". The first byte is already '\0': \0 ? ? ?. Why this step? The empty string is not "no bytes" — it is one byte, the terminator, sitting at index $0$ .
strlen(e) looks at e[0], sees '\0' immediately, stops with counter $= 0$ . Why this step? This is the degenerate limit of the counting loop: it never runs a single increment.
strcpy(e, "") would copy exactly one byte (the '\0') — always safe, even into a $1$ -byte buffer.

Recall Verify

Reveal ::: strlen("") == 0 ✓; it still occupies $1$ byte (the terminator).

Cell E — missing terminator (runaway scan)

Worked example Ex 5 · An array of chars with

no '\0'

char bad[3] = {'a', 'b', 'c'};   // NOTE: no room for, and no, '\0'
printf("%zu\n", strlen(bad));    // DANGER

Forecast: bad clearly holds $3$ letters. Will strlen print $3$ ?

Spot the trap. {'a','b','c'} fills all $3$ slots. There is no '\0' anywhere. Why this step? Curly-brace init does not append a terminator when the array is exactly full — unlike a string literal.
Run strlen. It counts a(1) b(2) c(3) then reads bad[3] — outside the array — and keeps going, counting whatever random bytes lie beyond until it accidentally meets a $0$ . Why this step? Without the stop signal the loop cannot terminate at $3$ ; it walks into your neighbour's memory (the dashed boxes).
Result: undefined — could print $3$ , $17$ , or crash. There is no correct answer. Why this step? Cell E shows that "the letters are right" is not enough: the terminator is the contract, not the letters.

Recall Verify

Reveal ::: intended length $3$ , but declared bytes $= 3$ with no terminator ⇒ 3 + 1 = 4 > 3, so no '\0' fits ⇒ scan is undefined ✓.

Cell F — concatenation overflow

Measure the pieces. strlen("Hi") = 2, strlen("there") = 5. Why this step? strcat glues them, so the final string is "Hithere" of length $7$ .
Compute bytes needed. result length $+ 1 = 7 + 1 = 8$ bytes. Why this step? The rule is strlen(dst) + strlen(src) + 1 — the $+ 1$ is the single joined terminator.
Compare to buffer. $8 > 6$ ⇒ overflow by $2$ bytes (dashed boxes in the figure). Why this step? strcat first walks to dst's '\0' at index $2$ , then copies t h e r e '\0' starting there — indices $2..7$ , but valid indices stop at $5$ .

Recall Verify

Reveal ::: 2 + 5 + 1 = 8 needed, buffer $6$ , overflow $= 8 - 6 = 2$ bytes ✓; strlen("Hithere") == 7.

Cell G — limiting cost behaviour (quadratic strcat)

Worked example Ex 7 · Why building a string with repeated

strcat is $O (n^{2})$

char big[1001] = "";
for (int k = 0; k < 1000; k++)
    strcat(big, "x");   // append one char, 1000 times

Forecast: Each strcat looks trivial. But how many byte-reads does the whole loop do?

Recall strcat's hidden scan. Before appending, it walks dst from the start to its '\0'. That is $O (len_{d s t})$ every single time (Time Complexity). Why this step? The append itself is cheap ( $1$ char), but finding the end is not.
Sum the scans. On iteration $k$ the current length is $k$ , so the scan costs about $k$ reads. Total: $\sum_{k = 0}^{999} k = \frac{999 \cdot 1000}{2} = 499500.$ Why this step? Adding up $0 + 1 + 2 + \dots + 999$ uses the arithmetic-series formula — that is the "Shlemiel the painter" curve.
Interpret. To append $1000$ single characters we performed $\approx 5 \times 1 0^{5}$ byte-reads — quadratic in $n$ , not linear. Why this step? This is the limiting behaviour cell: correctness is fine, but the cost blows up as $n$ grows.

Recall Verify

Reveal ::: $\sum_{k = 0}^{999} k = \frac{999 \cdot 1000}{2} = 499500$ ✓.

Cell H — sprintf output longer than the buffer

Worked example Ex 8 · A single

%d that overflows

char buf[4];
int id = 12345;
sprintf(buf, "%d", id);   // DANGER

Forecast: buf is $4$ bytes. 12345 is a number — how many characters does it become?

Format the number. %d turns 12345 into the $5$ characters '1' '2' '3' '4' '5'. Why this step? sprintf writes text, not a raw int — five digits (printf format specifiers).
Add the terminator. sprintf always appends '\0' ⇒ $5 + 1 = 6$ bytes written. Why this step? Even the safe count needs the $+ 1$ ; here it makes the overflow worse.
Compare to buffer. $6 > 4$ ⇒ overflow by $2$ bytes. sprintf never saw buf's size, so it cannot stop. Why this step? Cell H is the sprintf-specific danger: the size is simply not one of its arguments.

Recall Verify

Reveal ::: digits of $12345 = 5$ , needed $= 5 + 1 = 6$ , buffer $4$ , overflow $= 2$ ✓.

Cell I — the `sizeof` trap across a function

Worked example Ex 9 · Why

sizeof buf lies inside a function

void fill(char *buf) {
    snprintf(buf, sizeof buf, "%d", 12345);   // BUG: sizeof buf == 8, not 64
}
char store[64];
fill(store);

Forecast: store is $64$ bytes. Inside fill, what does sizeof buf evaluate to?

Array decays to pointer. When store is passed, the parameter buf is a char *, not an array (Arrays vs Pointers). Why this step? A pointer only holds an address — it forgot the array is $64$ bytes long.
Evaluate sizeof buf. On a $64$ -bit machine, sizeof a char * is $8$ (pointer size), not $64$ . Why this step? sizeof on a real array gives its byte count; on a pointer it gives the pointer's own size.
Consequence. snprintf is told the buffer is only $8$ bytes, so it truncates output at $8$ even though $64$ were available — a silent capacity bug (and would be catastrophic if the intent had been a plain sizeof-based strcpy). Why this step? Cell I shows the danger is not overflow but a wrong size number at a function boundary.

Recall Verify

Reveal ::: inside fill, sizeof buf == 8 (pointer), but real array sizeof store == 64 ✓ — they differ.

Cell J — the safe fix (snprintf truncation)

Worked example Ex 10 · Real-world: build a filename that is too long

char path[8];
int n = snprintf(path, sizeof path, "log_%d.txt", 2024);
// path == ?   n == ?

Forecast: The full text "log_2024.txt" is long. With only $8$ bytes, does this crash?

Compute the would-be full length. "log_2024.txt" = $12$ characters. snprintf returns the length it would have written (excluding '\0'), so n == 12. Why this step? This return value is how you detect truncation: if n >= sizeof path, output was cut.
What actually lands in path. snprintf writes at most size - 1 = 7 characters plus a guaranteed '\0': l o g _ 2 0 2 '\0' ⇒ path == "log_202". Why this step? Cell J is the safe counterpart to Cell H: instead of overflowing, snprintf truncates and always terminates.
Check for truncation. Since $n = 12 \geq sizeof path = 8$ , the caller knows the name was truncated and can react (allocate more, error out). Why this step? This is the whole point of the n-functions — a seat-belt that reports the crash it prevented.

Recall Verify

Reveal ::: full length of "log_2024.txt" $= 12$ (so n == 12); stored chars $= 8 - 1 = 7$ , giving "log_202" ✓.

Connections

Parent topic — the tools these examples exercise.
Buffer Overflow & Memory Safety — Cells C, F, H are all overflows.
Undefined Behaviour in C — why Cells C, E have no defined answer.
Arrays vs Pointers — Cell I, the sizeof trap.
Time Complexity — Cell G, the quadratic strcat.
printf format specifiers — Cells H, J, how %d/%s expand.