ftok(3)

✨ ftok(3) — the key generator bestie ✨

okay so this is ftok from section 3 of the manual (yes, the library functions girlies), and she's here to turn a file path + a project id into a System V IPC key. iconic behaviour honestly.

---

💖 NAME 💖

ftok — convert a pathname and a project identifier to a System V IPC key

🎀 LIBRARY 🎀

Standard C library (libc, -lc)

🦋 SYNOPSIS 🦋

#include <sys/ipc.h>

key_t ftok(const char *path, int proj_id);

🌸 DESCRIPTION 🌸

so what does she actually do? ftok() takes the identity of the file named by path — and btw that file has to actually exist and be accessible, no ghost files allowed — and smooshes it together with the least significant 8 bits of proj_id (which must be nonzero, more on that drama in NOTES). out comes a key_t type System V IPC key, ready to be handed to msgget(2), semget(2), or shmget(2). slay.

the resulting value is the same for all pathnames that name the same file, as long as you're using the same value of proj_id. and the value returned should be different when the (simultaneously existing) files or the project IDs differ. like, that's the whole point bestie 💅

🔥 RETURN VALUE 🔥

• on success: the generated key_t value is returned. ate.
• on failure: -1 is returned, and errno tells you what went wrong, same as it does for the stat(2) system call. 😭

💅 ATTRIBUTES 💅

for an explanation of the terms used in this section, see attributes(7).

• Interface: ftok()
• Attribute: Thread safety
• Value: MT-Safe

so yeah, she's MT-Safe, thread-safe queen, no cap 👑

⭐ STANDARDS ⭐

POSIX.1-2008.

🌈 HISTORY 🌈

POSIX.1-2001. she's been around a minute, fr fr.

👑 NOTES 👑

okay bestie this is the part where we get into the lore. on some ancient systems, the prototype was:

key_t ftok(char *path, char proj_id);

today, proj_id is an int, but still only 8 bits are used. typical usage has an ASCII character as proj_id, which is why the behavior is said to be undefined when proj_id is zero. so like… don't do that. 🫶

and of course, no guarantee can be given that the resulting key_t is unique. typically, a best-effort attempt combines the given proj_id byte, the lower 16 bits of the inode number, and the lower 8 bits of the device number into a 32-bit result. collisions may easily happen — for example, between files on /dev/hda1 and files on /dev/sda1. it's giving ✨chaos✨ ngl.

not me warning you about collisions twice: seriously, two different files can absolutely produce the same key. vibe check your keys before you commit, ok?

🍓 EXAMPLES 🍓

See semget(2).

💜 SEE ALSO 💜

msgget(2), semget(2), shmget(2), stat(2), sysvipc(7)

---

okk that's the whole page, mwah 💋 this one came from Linux man-pages 6.20, dated 2026-02-08, and it's your girl ftok(3) signing off — go make some IPC keys, but responsibly 🎀✨🦋