memcpy(3)

💖 memcpy(3) — the memory-copy bestie 💖

okay so we're doing memcpy, and honestly? iconic. this is the girl who moves your bytes from one place to another and does it FAST. she's in the Library Functions Manual and she lives in the Standard C library (libc, -lc). she's everywhere. you've used her a thousand times. let's get into it 🫶

---

✨ NAME ✨

memcpy — memory copy. that's it. that's the whole job. and she ATE. 💅

---

📚 LIBRARY 📚

Standard C library (libc, -lc)

like yeah bestie she's standard, she's built in, she's not going anywhere. skip the -lm nonsense, this is the real deal. ✨

---

🎀 SYNOPSIS 🎀

#include <string.h>  // see memory.h(3head)

and the signature, verbatim, exactly as written:

void *memcpy(size_t n;
             void dest[restrict n], const void src[restrict n],
             size_t n);

okay yes the header comment sends you to memory.h(3head), go look, we don't gatekeep here 🌸

---

💫 DESCRIPTION 💫

so here's the tea. memcpy() copies n bytes from memory area src to memory area dest. that's it! that's her job! bytes go in one end, bytes come out the other end, and they're the same bytes 💖

but. and this is the big but, the one your CS professor screamed about. the memory areas must not overlap. like, at all. not even a little. not even for one byte.

if your areas DO overlap? you do not call memcpy(). you call memmove(3) instead, because memmove(3) is the bestie who actually checks and handles it. memcpy() is the fast girl who assumes you know what you're doing. respect her boundaries, babe. 🦋

---

🫶 RETURN VALUE 🫶

memcpy() returns a pointer to dest. she hands you back the destination like "here you go bestie, she's all yours" 😭💜

---

🌈 ATTRIBUTES 🌈

for the deets on what all these terms even mean, hit up attributes(7). (that's a whole other man page, go read it, i'll wait 💅)

here's the chart, but make it a vibe:

• memcpy() — Thread safety: MT-Safe

that's it! MT-Safe! she's multithread safe! she's not out here corrupting your threads, she knows what she's doing, she's got main character energy in every thread. slay. 👑

---

⭐ STANDARDS ⭐

C11, POSIX.1-2008.

she's officially official. certified. no cap. 🎀

---

🧚 HISTORY 🧚

POSIX.1-2001, C89, SVr4, 4.3BSD.

she's been around. she's seen things. she's a legacy icon and she's still the most-used function in your codebase. that's longevity bestie. 🕰️✨

---

💀 CAVEATS 💀

okay sit down. this is the part that's giving lore.

so failing to observe the requirement that the memory areas do not overlap has been the source of significant bugs. significant. as in, real production outages, real 3am pager duty, real "why is my data garbled" energy. 😭

(POSIX and the C standards are explicit that employing memcpy() with overlapping areas produces undefined behavior. undefined. as in, anything can happen. no promises. no take-backs. 💀)

most notably — and this is the drama — in glibc 2.13 a performance optimization of memcpy() on some platforms (including x86-64) included changing the order in which bytes were copied from src to dest.

and this change revealed breakages in a number of applications that performed copying with overlapping areas. 😳

here's why that's so juicy: under the previous implementation, the order in which the bytes were copied had fortuitously hidden the bug — it just happened to work! — which was revealed when the copying order was reversed. like, the bug was always there, the old code was just covering for it. the way that a refactor can expose a decade of sloppy code is honestly kind of iconic 💅

so what did they do? in glibc 2.14, a versioned symbol was added so that old binaries (i.e., those linked against glibc versions earlier than 2.14) employed a memcpy() implementation that safely handles the overlapping buffers case — by providing an "older" memcpy() implementation that was aliased to memmove(3).

so if your binary is old, you get the safe one. if it's new, you get the fast one and you're on your own. respect the versioning, it's doing a lot of heavy lifting. 👑

fr fr: do not pass overlapping buffers to memcpy(). if they overlap, that's memmove(3). do not test fate. do not "but it worked on my machine". it did NOT work, it just hadn't been caught yet. 💀

---

🍓 SEE ALSO 🍓

• memory.h(3head) — the header bestie who spilled the tea
• memmove(3) — the safe one, the overlap handler, the responsible queen
• mempcpy(3) — memcpy() but she hands you back the end pointer instead, icon behavior
• wmemcpy(3) — same energy, wide characters, multilingual slay 🌈

---

🌸 FINAL VIBE CHECK 🌸

that's the page bestie! she's a one-job icon: copy n bytes, don't overlap, return dest. 🎀💖

and a lil' sign-off for the credits: this was Linux man-pages version 6.20, dated 2026-08-10. shoutout to the whole man-pages crew, they really do keep us fed 🫶✨

now go forth and memcpy() responsibly. periodt. 💅👑