F_GETFD(2const)
β¨ F_GETFD β¨
okay bestie, this is a 2const page β meaning it's one lil slice of the big fcntl(2) family β and it's all about getting and setting the flags on a file descriptor. That's it. That's the whole vibe. π
π NAME π
F_GETFD, F_SETFD β get/set file descriptor flags
π LIBRARY π
Standard C library (libc, -lc) β your everyday ride-or-die, no special linking era needed.
πΈ SYNOPSIS πΈ
#include <fcntl.h>
int fcntl(int fd, F_GETFD);
int fcntl(int fd, F_SETFD, int arg);
π DESCRIPTION π
So these two operations (they're commands you hand to fcntl(2)) manipulate the flags associated with a file descriptor. Like, the descriptor itself has its own lil flag collection. Not the file's flags β the descriptor's. Important distinction, periodt.
Currently, only one such flag is even defined: FD_CLOEXEC, a.k.a. the close-on-exec flag. Only one. That's the whole roster. π
Here's the tea:
- If the
FD_CLOEXECbit is set, the file descriptor will automatically be closed during a successfulexecve(2). β¨ (But if theexecve(2)fails, the file descriptor is left open. Just so you know. Not me being extra, that's literally what it says.) - If the
FD_CLOEXECbit is not set, the file descriptor will remain open across anexecve(2).
Now the two operations themselves:
F_GETFD
Return (as the function result) the file descriptor flags. And arg? Ignored. It's giving "you didn't need to bring that." π
F_SETFD
Set the file descriptor flags to the value specified by arg. Slay, you're in charge now.
π₯ RETURN VALUE π₯
F_GETFD
Value of file descriptor flags. (The flags come back as the return value itself, bestie.)
F_SETFD
Zero.
And if things go wrong β on error, -1 is returned, and errno is set to indicate the error. π
π ERRORS π
See fcntl(2). That's where all the error deets live, we're just pointing you there. π«Ά
π STANDARDS π
POSIX.1-2024. Certified. Official. Iconic.
π¦ HISTORY π¦
SVr4, 4.3BSD, POSIX.1-1988. Ancient lineage fr fr, this one's been around.
β οΈ CAVEATS β οΈ
okay this part matters, listen up. π¨
In multithreaded programs, using fcntl(2) F_SETFD to set the close-on-exec flag at the same time as another thread performs a fork(2) plus execve(2) is vulnerable to a race condition that may unintentionally leak the file descriptor to the program executed in the child process.
Like β you did NOT mean to hand that fd to the child, and yet. π
See the discussion of the O_CLOEXEC flag in open(2) for details and a remedy to the problem. (Yes there's a fix, go read it, iykyk.)
π SEE ALSO π
that's the whole page bestie π every flag, every caveat, every last return value β kept it all, just made it cute. this one's from Linux man-pages 6.20, dated 2026-01-05, and honestly? obsessed with her. πβ¨
π¦ where this page comes from
- arch rolling: man-pages 6.20-1 Β· BSD-2-Clause AND BSD-3-Clause AND BSD-4.3TAHOE AND BSD-4-Clause-UC AND GPL-1.0-or-later AND GPL-2.0-only AND GPL-2.0-or-later AND GPL-3.0-or-later AND LGPL-3.0-linking-exception AND LGPL-3.0-or-later AND LicenseRef-Public-Domain AND LicenseRef-UltraPermissive AND Linux-man-pages-1-para AND Linux-man-pages-copyleft AND Linux-man-pages-copyleft-2-para AND Linux-man-pages-copyleft-var AND MIT AND Spencer-94
- nixpkgs unstable: man-pages 6.20
- π the page's license: Linux-man-pages-copyleft
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms