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

5.1.20 · D3 · Coding › C Programming › String handling — char arrays, null terminator, strcpy, strc

Scenario matrix

Kisi bhi example se pehle, har distinct situation list karte hain jisme ek C string ho sakti hai. Agar koi bug ya surprise hai, woh in rows mein se kisi ek mein rehta hai.

Cell	Case class	Kya special hai	Covered by
A	Normal string, room to spare	length + `'\0'` easily buffer mein fit ho jaata hai	Ex 1
B	Buffer exactly full	`len + 1 == size` (the boundary)	Ex 2
C	Off-by-one overflow	`len + 1 > size` exactly ek byte se	Ex 3
D	Empty / degenerate string	length $0$ , pehla byte `'\0'` hai	Ex 4
E	Missing terminator	array mein koi `'\0'` nahi → 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 buffer se lamba	formatted text silently overflow karta hai	Ex 8
I	`sizeof` trap across a function boundary	`char *` param vs real array	Ex 9
J	Bounded `snprintf` truncation (safe fix)	output too long but koi overflow nahi	Ex 10

Neeche har figure mein do colour conventions use hue hain:

Cell A — normal string with room

Worked example Ex 1 ·

strlen aur copy with a roomy buffer

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

Forecast: src kitne bytes use karta hai? printf kya print karega? Kya dst overflow hoga?

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

src ke bytes count karo. "dog" hai d o g '\0' = $4$ bytes. Yeh step kyun? Kyunki copy ko sabhi bytes move karni hain including terminator — figure mein coral box dekho.
dst[8] mein copy karo. Hum $4$ bytes ek $8$ -byte array mein likhte hain. $4 \leq 8$ , toh koi overflow nahi. Yeh step kyun? Cell A "room to spare" se define hota hai — yeh safe baseline hai jiske against baad ke har bug ko measure karte hain.
my_strlen(dst) scan karta hai d(1) o(2) g(3) '\0'(stop) aur return karta hai $3$ . Yeh step kyun? Length '\0' se pehle ke characters count karta hai, isliye count $3$ hai, $4$ nahi.

Recall Verify

Reveal ::: strlen("dog") == 3, copy ko $4$ bytes chahiye, $4 \leq 8$ ✓ koi overflow nahi.

Cell B — buffer exactly full (the boundary)

Terminator add karo. "cat" = c a t '\0' = $4$ bytes. Yeh step kyun? Har string literal silently '\0' append karta hai — aapko uske liye budget rakhna hoga.
a[4] mein fit karo. $4$ bytes $4$ bytes mein: exactly full, len + 1 == size. Yeh step kyun? Yeh boundary case hai — legal hai, lekin zero slack hai. Ek aur character aur hum Cell C mein hain.
strlen(a) scan karta hai c(1) a(2) t(3) '\0' → return karta hai $3$ .

Recall Verify

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

Cell C — off-by-one overflow

Worked example Ex 3 ·

char[5] mein "Hello" — classic one-byte trap

char buf[5];
strcpy(buf, "Hello");   // DANGER

Forecast: "Hello" $5$ letters hai aur buffer $5$ hai. Theek lagta hai — kya sach mein hai?

Jo likhna hai usse count karo. "Hello" = H e l l o '\0' = $6$ bytes. Yeh step kyun? Paanch letters visible hain; chhata byte ('\0') invisible hai lekin mandatory hai.
Buffer se compare karo. $6 > 5$ . strcpy byte index $5$ likhta hai array ke last valid index $4$ ke baad. Yeh step kyun? Cell C exactly len + 1 > size ek se hai — C mein sabse common real bug.
C kya karta hai: kuch nahi rokta. Figure mein dashed coral box (neighbour ka byte) mein $0$ likh deta hai → buffer overflow, undefined behaviour. Yeh step kyun? Koi bounds check nahi (Buffer Overflow & Memory Safety); corruption ab crash kar sakta hai, baad mein, ya exploit ho sakta hai.

Recall Verify

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

Cell D — empty / degenerate string

"" ka layout. Pehla byte already '\0' hai: \0 ? ? ?. Yeh step kyun? Empty string "no bytes" nahi hai — yeh ek byte hai, terminator, index $0$ par baitha hai.
strlen(e) e[0] dekhta hai, turant '\0' milta hai, counter $= 0$ ke saath ruk jaata hai. Yeh step kyun? Yeh counting loop ki degenerate limit hai: ek bhi increment nahi chalta.
strcpy(e, "") exactly ek byte copy karega ('\0') — hamesha safe, chahe $1$ -byte buffer mein bhi.

Recall Verify

Reveal ::: strlen("") == 0 ✓; phir bhi $1$ byte occupy karta hai (the terminator).

Cell E — missing terminator (runaway scan)

Worked example Ex 5 · Chars ka ek array

bina '\0' ke

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

Forecast: bad clearly $3$ letters hold karta hai. Kya strlen $3$ print karega?

Trap pakdo. {'a','b','c'} teeno slots fill kar deta hai. Kahin koi '\0' nahi hai. Yeh step kyun? Curly-brace init terminator append nahi karta jab array exactly full ho — string literal se alag.
strlen chalao. Woh a(1) b(2) c(3) count karta hai phir bad[3] read karta hai — array ke bahar — aur chalata rehta hai, jo bhi random bytes aage hain unhe count karta hai jab tak accidentally $0$ nahi milta. Yeh step kyun? Stop signal ke bina loop $3$ par terminate nahi ho sakta; woh neighbour ki memory mein walk kar jaata hai (dashed boxes).
Result: undefined — $3$ print ho sakta hai, $17$ , ya crash. Koi correct answer nahi. Yeh step kyun? Cell E dikhata hai ki "letters sahi hain" kaafi nahi: terminator contract hai, letters nahi.

Recall Verify

Reveal ::: intended length $3$ , lekin declared bytes $= 3$ bina terminator ke ⇒ 3 + 1 = 4 > 3, toh koi '\0' fit nahi hoti ⇒ scan undefined hai ✓.

Cell F — concatenation overflow

Pieces measure karo. strlen("Hi") = 2, strlen("there") = 5. Yeh step kyun? strcat inhe jodta hai, toh final string "Hithere" hai length $7$ ki.
Bytes needed compute karo. result length $+ 1 = 7 + 1 = 8$ bytes. Yeh step kyun? Rule hai strlen(dst) + strlen(src) + 1 — $+ 1$ single joined terminator hai.
Buffer se compare karo. $8 > 6$ ⇒ overflow by $2$ bytes (figure mein dashed boxes). Yeh step kyun? strcat pehle dst ke '\0' tak walk karta hai index $2$ par, phir t h e r e '\0' wahan se copy karta hai — indices $2..7$ , lekin valid indices $5$ tak rukti hain.

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 · Repeated

strcat se string banana $O (n^{2})$ kyun hai

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

Forecast: Har strcat trivial lagta hai. Lekin poora loop kitne byte-reads karta hai?

strcat ka hidden scan yaad karo. Append karne se pehle, woh dst ko start se '\0' tak walk karta hai. Har baar $O (len_{d s t})$ cost hai (Time Complexity). Yeh step kyun? Append khud sasta hai ( $1$ char), lekin end dhundhna nahi.
Scans sum karo. Iteration $k$ par current length $k$ hai, toh scan karta hai lagbhag $k$ reads. Total: $\sum_{k = 0}^{999} k = \frac{999 \cdot 1000}{2} = 499500.$ Yeh step kyun? $0 + 1 + 2 + \dots + 999$ add karne mein arithmetic-series formula use hota hai — yeh "Shlemiel the painter" curve hai.
Interpret karo. $1000$ single characters append karne ke liye humne $\approx 5 \times 1 0^{5}$ byte-reads kiye — $n$ mein quadratic, linear nahi. Yeh step kyun? Yeh limiting behaviour cell hai: correctness theek hai, lekin cost $n$ badhne ke saath explode hoti hai.

Recall Verify

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

Cell H — sprintf output buffer se lamba

Worked example Ex 8 · Ek single

%d jo overflow karta hai

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

Forecast: buf $4$ bytes hai. 12345 ek number hai — kitne characters banta hai?

Number format karo. %d 12345 ko $5$ characters '1' '2' '3' '4' '5' mein badalta hai. Yeh step kyun? sprintf text likhta hai, raw int nahi — paanch digits (printf format specifiers).
Terminator add karo. sprintf hamesha '\0' append karta hai ⇒ $5 + 1 = 6$ bytes likhe. Yeh step kyun? Safe count mein bhi $+ 1$ chahiye; yahan woh overflow aur bura karta hai.
Buffer se compare karo. $6 > 4$ ⇒ overflow by $2$ bytes. sprintf ne kabhi dekha hi nahi buf ka size, toh woh rok nahi sakta. Yeh step kyun? Cell H sprintf-specific danger hai: size simply uske arguments mein se ek nahi hai.

Recall Verify

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

Cell I — `sizeof` trap across a function

Worked example Ex 9 · Function ke andar

sizeof buf kyun jhooth bolta hai

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

Forecast: store $64$ bytes hai. fill ke andar sizeof buf kya evaluate karta hai?

Array pointer mein decay karta hai. Jab store pass hota hai, parameter buf ek char * hai, array nahi (Arrays vs Pointers). Yeh step kyun? Pointer sirf ek address hold karta hai — woh bhool jaata hai ki array $64$ bytes lamba hai.
sizeof buf evaluate karo. $64$ -bit machine par, ek char * ka sizeof $8$ hai (pointer size), $64$ nahi. Yeh step kyun? Real array par sizeof uska byte count deta hai; pointer par woh pointer ka apna size deta hai.
Consequence. snprintf ko bataya jaata hai ki buffer sirf $8$ bytes hai, toh woh output $8$ par truncate karta hai chahe $64$ available the — ek silent capacity bug (aur catastrophic hota agar intent plain sizeof-based strcpy ka hota). Yeh step kyun? Cell I dikhata hai ki danger overflow nahi balki function boundary par ek galat size number hai.

Recall Verify

Reveal ::: fill ke andar, sizeof buf == 8 (pointer), lekin real array sizeof store == 64 ✓ — dono alag hain.

Cell J — safe fix (snprintf truncation)

Worked example Ex 10 · Real-world: ek filename banana jo too long hai

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

Forecast: Full text "log_2024.txt" lamba hai. Sirf $8$ bytes ke saath, kya yeh crash karta hai?

Pura would-be length compute karo. "log_2024.txt" = $12$ characters. snprintf woh length return karta hai jo woh likhta (excluding '\0'), toh n == 12. Yeh step kyun? Yeh return value hai jisse truncation detect karte hain: agar n >= sizeof path, output cut hua.
path mein actually kya aata hai. snprintf at most size - 1 = 7 characters plus ek guaranteed '\0' likhta hai: l o g _ 2 0 2 '\0' ⇒ path == "log_202". Yeh step kyun? Cell J Cell H ka safe counterpart hai: overflow karne ki jagah, snprintf truncate karta hai aur hamesha terminate karta hai.
Truncation check karo. Kyunki $n = 12 \geq sizeof path = 8$ , caller jaanta hai ki naam truncate hua aur react kar sakta hai (aur allocate karo, error out karo). Yeh step kyun? Yahi toh n-functions ka poora point hai — ek seat-belt jo us crash ki report karta hai jise usne roka.

Recall Verify

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

Connections

Parent topic — woh tools jinhe yeh examples exercise karte hain.
Buffer Overflow & Memory Safety — Cells C, F, H sab overflows hain.
Undefined Behaviour in C — isliye Cells C, E ka koi defined answer nahi.
Arrays vs Pointers — Cell I, sizeof trap.
Time Complexity — Cell G, quadratic strcat.
printf format specifiers — Cells H, J, %d/%s kaise expand karte hain.