DIRFD(3POSIX)

🦋 DIRFD(3POSIX) 🦋

okay bestie, welcome to the POSIX Programmer's Manual — this is the whole vibe for dirfd, the little function that pulls an fd out of your directory stream. let's get into it 💅

---

💫 PROLOG 💫

This manual page is part of the POSIX Programmer's Manual. Real talk though: the Linux implementation of this interface may differ (so go consult the corresponding Linux manual page for the deets on Linux behavior), or honestly the interface may not be implemented on Linux at all. 🙈 no cap.

---

✨ NAME ✨

dirfd — extract the file descriptor used by a DIR stream

like. it hands you the fd that's hiding inside your DIR. that's the whole job. iconic. 🎀

---

🌸 SYNOPSIS 🌸

#include <dirent.h>

int dirfd(DIR *dirp);

---

💜 DESCRIPTION 💜

okay so the dirfd() function shall return a file descriptor referring to the same directory as the dirp argument. cute, right? and this file descriptor shall be closed by a call to closedir().

⚠️ bestie listen — if any attempt is made to close the file descriptor, or to modify the state of the associated description, other than by means of closedir(), readdir(), readdir_r(), rewinddir(), or seekdir(), the behavior is undefined. literally undefined. not "kinda weird", not "a little buggy" — undefined. don't do it. 💀

---

🎀 RETURN VALUE 🎀

Upon successful completion, the dirfd() function shall return an integer which contains a file descriptor for the stream pointed to by dirp. ✨

Otherwise, it shall return -1 and shall set errno to indicate the error. 😭 the classic.

---

🔥 ERRORS 🔥

The dirfd() function may fail if:

• EINVAL — the dirp argument does not refer to a valid directory stream. 🫠 like you handed it a vibe that isn't a directory stream at all.

Also heads up: the following sections are informative. not normative, just lore. 🌈

---

🍓 EXAMPLES 🍓

None.

...yeah. not a single example. that's it. that's the section. 💀

---

🌈 APPLICATION USAGE 🌈

The dirfd() function is intended to be a mechanism by which an application may obtain a file descriptor to use for the fchdir() function. that's literally the point of it — you want the fd so you can fchdir() into that directory. the way that works is so clean honestly. 🫶

---

🧚 RATIONALE 🧚

so why does this exist? This interface was introduced because the Base Definitions volume of POSIX.1‐2017 does not make public the DIR data structure — so apps had no way to peek inside and grab the fd themselves. rude, honestly. Applications tend to use the fchdir() function on the file descriptor returned by this interface, and this has proven useful for security reasons; in particular, it is a better technique than others where directory names might change. 🔒 slay for security.

now, a lil language moment: the description uses the term "a file descriptor" rather than "the file descriptor". The implication intended is that an implementation that does not use an fd for opendir() could still open() the directory to implement the dirfd() function. Such a descriptor must be closed later during a call to closedir(). periodt.

and one more: if it is necessary to allocate an fd to be returned by dirfd(), it should be done at the time of a call to opendir(). like, do it early bestie. plan ahead. 🎀

---

⭐ FUTURE DIRECTIONS ⭐

None.

the future is... unchanged. it's giving stable. 👑

---

👑 SEE ALSO 👑

• closedir()
• fchdir()
• fdopendir()
• fileno()
• open()
• readdir()

The Base Definitions volume of POSIX.1‐2017, <dirent.h>

---

💖 COPYRIGHT 💖

okay this part is the legal bit and we keep it exactly as written, no edits, iykyk:

Portions of this text are reprinted and reproduced in electronic form from IEEE Std 1003.1-2017, Standard for Information Technology -- Portable Operating System Interface (POSIX), The Open Group Base Specifications Issue 7, 2018 Edition, Copyright (C) 2018 by the Institute of Electrical and Electronics Engineers, Inc and The Open Group. In the event of any discrepancy between this version and the original IEEE and The Open Group Standard, the original IEEE and The Open Group Standard is the referee document. The original Standard can be obtained online at http://www.opengroup.org/unix/online.html .

Any typographical or formatting errors that appear in this page are most likely to have been introduced during the conversion of the source files to man page format. To report such errors, see https://www.kernel.org/doc/man-pages/reporting_bugs.html .

---

and that's the page!! shoutout to IEEE/The Open Group for dropping this in 2017 — we love a standards body that keeps receipts. go get your fd bestie, and close it with closedir() or the behavior will be undefined and we will be sad 💖🦋✨