The unsafe functions strcpy and sprintf write characters until they hit a '\0' — they never check the size of the destination . If the source is bigger than the buffer, they walk straight off the end and corrupt memory (buffer overflow). The "safe" family asks you for one extra argument: how big is the destination? That single number is the whole game. Master what each function does at exactly that boundary and you've mastered 80% of safe C string handling.
Definition Buffer overflowWriting past the end of an array. In C, char buf[8] is just 8 bytes; nothing stops you from writing a 9th. The 9th byte lands on whatever memory follows — another variable, a return address, anything. This is the #1 source of security exploits in C.
char buf [ 8 ]; strcpy (buf, "hello world" ); // 12 bytes into 8 → OVERFLOW The fix: pass the size of buf so the copy can stop in time . Three tools do this, and they differ in one crucial detail each .
strncpy(dest, src, n)
Copies at most n bytes from src to dest.
If src is shorter than n: copies it, then pads the rest with '\0' .
If src is n bytes or longer: copies exactly n bytes and does NOT add a terminating '\0' .
Common mistake Steel-man: "strncpy always null-terminates, so it's safe."
Why it feels right: the n looks like a max length and the name screams "safe strcpy". You assume it leaves you a proper C string.
The trap: when src fills the buffer exactly (or overflows it), strncpy leaves no '\0' . Your "string" now has no end → the next printf/strlen reads off into garbage.
The fix: always force-terminate yourself:
strncpy (dest, src, sizeof (dest) - 1 ); dest [ sizeof (dest) - 1 ] = ' \0 ' ; // guarantee termination
Worked example strncpy with a short source — "Why this step?"char buf [ 8 ]; strncpy (buf, "hi" , sizeof (buf)); // src="hi" (2 chars) Result bytes: 'h' 'i' '\0' '\0' '\0' '\0' '\0' '\0'.
Why? Source is shorter than n=8, so after copying hi\0 it pads the remaining 5 bytes with zeros . Safe and properly terminated — by luck, because the source was short.
Worked example strncpy with an oversized source — the dangerous casechar buf [ 8 ]; strncpy (buf, "0123456789" , sizeof (buf)); // 10 chars into 8 Result bytes: '0' '1' '2' '3' '4' '5' '6' '7' — no '\0' anywhere!
Why this step matters: strlen(buf) now reads past byte 7 into adjacent memory. The fix line buf[7] = '\0' makes it 01234567 — content truncated but a valid string.
snprintf(dest, size, format, ...)
Like sprintf, but writes at most size bytes total, including the '\0' . It always null-terminates (as long as size > 0). It returns the number of characters that would have been written if there were room (excluding the '\0').
Intuition WHAT the return value tells youThe return value r r r needed length, not the written length. If r ≥ size r \ge \text{size} r ≥ size truncation happened . This is gold: you can detect overflow without re-scanning.
truncated ⟺ r ≥ size \text{truncated} \iff r \ge \text{size} truncated ⟺ r ≥ size
Worked example snprintf building a message — "Why this step?"char buf [ 8 ]; int r = snprintf (buf, sizeof (buf), "id= %d " , 12345 ); "id=12345" is 8 chars, needs 9 bytes. Only 8 fit, so buf holds "id=1234" + '\0' (7 chars + null = 8 bytes), and r == 8.
Why r == 8? It reports the length it wanted (id=12345), so r (8) >= size (8) flags truncation. Why is buf still safe? snprintf reserved the last byte for '\0' no matter what — unlike strncpy.
Common mistake Steel-man: "snprintf's return value is how many bytes it wrote."
Why it feels right: most functions return what they did. Fix: it returns what it would have written. Use r >= size to detect truncation, not as a count of bytes in the buffer.
strlcpy(dest, src, size)
Copies up to size - 1 bytes from src, then always null-terminates (if size > 0). Returns strlen(src) — the length it tried to copy. If return ≥ \ge ≥ size, truncation occurred.
Note: not in standard C; available on BSD/macOS, and Linux glibc only since 2.38. Portable code can't always rely on it.
Intuition WHY strlcpy is the "best behaved"It combines the two good behaviors: it never overflows (like strncpy) and always terminates (like snprintf), without wasteful padding. It's the function strncpy should have been.
Worked example strlcpy — "Why this step?"char buf [ 8 ]; size_t r = strlcpy (buf, "0123456789" , sizeof (buf)); buf = "0123456" + '\0' (7 chars + null). r == 10.
Why r==10? It reports the full source length, so r (10) >= size (8) → you know you lost data.
Function
Caps to
Always null-terminates?
Return value
Truncation check
strcpynothing
yes (if no overflow)
dest ptr
❌ unsafe
strncpyn bytesNO dest ptr
manual
snprintfsize (incl. \0)YES would-be length
r >= size
strlcpysize-1YES strlen(src)ret >= size
Recall Feynman: explain to a 12-year-oldImagine pouring water into a cup. strcpy keeps pouring even when the cup is full — water spills everywhere and ruins your desk (that's a crash or a hack). The "safe" pourers first ask "how big is the cup?" strncpy stops pouring but sometimes forgets to put the lid on (no '\0'). snprintf always leaves room for the lid and tells you "you wanted more than fit." strlcpy is the polite one: stops in time, always puts the lid on, and whispers how much you actually had. The size argument is the question "how big is the cup?" — never skip it.
"n forgets the knot, printf and l always tie it."
str**n**cpy may forget the null knot ; s**n**printf and str**l**cpy always tie the knot (terminate).
What single extra argument makes the safe string functions safe? The size of the destination buffer , so the copy can stop before overflowing.
When does strncpy fail to null-terminate? When the source length is >= n (the size limit): it copies exactly n bytes and adds no '\0'.
What is the standard fix after a strncpy(dest, src, sizeof(dest)-1)? Manually set dest[sizeof(dest)-1] = '\0'; to guarantee termination.
Why copy at most sizeof(dest)-1, not sizeof(dest)? One byte must be reserved for the trailing '\0'; capacity − 1 is the max content.
Does snprintf always null-terminate? Yes, as long as size > 0, it always writes a terminating '\0'.
What does snprintf return and how do you detect truncation? It returns the number of chars it would have written (excluding '\0'); truncation happened iff return >= size.
How does strlcpy differ from strncpy? strlcpy always null-terminates and doesn't zero-pad; it caps at size-1 and returns strlen(src).
Why is strlcpy not always usable? It is non-standard (BSD origin); not on all platforms — glibc added it only in 2.38.
Given char b[8]; snprintf(b,8,"id=%d",12345); what is in b and what does it return? b = "id=1234" (7 chars + null); returns 8, flagging truncation since 8 >= 8.
What memory bug do these functions prevent? Buffer overflow — writing past the end of the destination array.
C strings and the null terminator Buffer overflow and stack smashing strcpy and sprintf (unsafe) sizeof vs strlen Format strings and printf family Memory safety and undefined behavior
Pads with nulls if src short
No null if src fills buffer
Intuition Hinglish mein samjhoDekho, C mein char buf[8] ka matlab hai sirf 8 byte ki jagah — usse zyada likhoge to memory overflow ho jaati hai, aur yahi cheez crash aur hacking ka sabse bada kaaran hai. strcpy aur sprintf size check hi nahi karte, isliye unhe "unsafe" bolte hain. Safe versions ek extra argument maangte hain: destination ka size kitna hai? Bas yahi ek number poora khel hai.
Teen tools yaad rakho. strncpy(dest, src, n) zyada se zyada n byte copy karta hai — par ek dhokha hai: agar source poora bhar gaya (n ya usse bada), to woh '\0' (null terminator) nahi lagaata . Tabhi humesha khud se dest[sizeof(dest)-1] = '\0'; likhna padta hai, warna string ka end hi nahi milega aur strlen/printf garbage padhne lagenge.
snprintf(dest, size, fmt, ...) sabse aaram-daayak hai: yeh humesha null-terminate karta hai aur kabhi overflow nahi karta. Iska return value bataata hai ki kitne characters likhne the (chahe room na ho) — agar return >= size, samajh jaao truncation ho gaya. strlcpy(dest, src, size) BSD ka hai, donon achhi baatein karta hai (overflow nahi, null hamesha lagta hai) aur strlen(src) return karta hai — par yeh standard C mein nahi hai, har platform pe nahi milega.
Yaad rakhne ka mantra: "n forgets the knot, printf aur l always tie it." Matlab strncpy null bhool sakta hai, par snprintf aur strlcpy hamesha null laga dete hain. Capacity C mein content hamesha C-1 tak hi, kyunki ek byte null ke liye reserve hai.
