READ(2)

💖 READ(2) — read input 💖

okay bestie, welcome to section 2 of the system calls manual, the part where we talk to the kernel directly and it actually answers. this is READ(2), aka the four functions that get bytes out of a file descriptor and into your little buffer. group chat is open, let's go 🫶

---

✨ NAME ✨

read, readv, pread, preadv — read input

📚 LIBRARY 📚

Standard C Library (libc, -lc)

---

🌸 SYNOPSIS 🌸

#include <unistd.h>

ssize_t
read(int fd, void *buf, size_t nbytes);

ssize_t
pread(int fd, void *buf, size_t nbytes, off_t offset);

#include <sys/uio.h>

ssize_t
readv(int fd, const struct iovec *iov, int iovcnt);

ssize_t
preadv(int fd, const struct iovec *iov, int iovcnt, off_t offset);

---

💅 DESCRIPTION 💅

so. the read() system call is out here trying to read nbytes of data from the object that the descriptor fd points at, and it drops that data into the buffer that buf points at. that's it, that's the whole job. iconic behavior honestly 🌈

then readv() does the exact same thing but it scatters — the input data gets spread across the iovcnt buffers listed in the members of the iov array: iov[0], iov[1], ..., iov[iovcnt-1]. it's giving "one call, many destinations", we love a multitasker ✨

and pread() + preadv() do those same functions but they read from the specified position in the file without touching the file pointer. no pointer drama. none. 🙈

---

🦋 the iovec situation 🦋

for readv() and preadv(), the iovec structure is defined like this:

struct iovec {
        void   *iov_base;  /* Base address. */
        size_t iov_len;    /* Length. */
};

every single iovec entry says "here's the base address and here's the length of a chunk of memory where data should go". and readv() will always fill an area completely before it moves on to the next one. no half-filled vibes, no crumbs, full commitment only. 💯

---

🎀 the pointer lore 🎀

on objects that are capable of seeking, read() starts at the position given by the pointer associated with fd — go check lseek(2) for that whole saga. and once read() returns, that pointer gets incremented by however many bytes were actually read. real ones know 📈

objects that are not capable of seeking? they always read from the current position, and the value of the pointer associated with such an object is undefined. don't ask, it's undefined, we don't look at it. 💀

---

⭐ the return guarantee ⭐

upon successful completion, read(), readv(), pread() and preadv() all return the number of bytes actually read and placed in the buffer.

here's the tea though: the system guarantees to read the number of bytes requested if the descriptor references a normal file that has that many bytes left before the end-of-file. and in no other case. that's the whole guarantee, bestie, don't extrapolate. 😭

---

👑 atomicity, because we're serious now 👑

in accordance with IEEE Std 1003.1-2004 (“POSIX.1”), both read(2) and write(2) syscalls are atomic with respect to each other in the effects on file content, when they operate on regular files.

if two threads each call one of the read(2) or write(2) syscalls, each call will see either all of the changes of the other call, or none of them. no in-between, no "oops i saw half a write". the FreeBSD kernel implements this guarantee by locking the file ranges affected by the calls. periodt. 🔒

---

🌟 RETURN VALUES 🌟

if it worked, you get the number of bytes actually read. if you hit end-of-file, you get zero. otherwise you get a -1 and the global variable errno is set to tell you what went wrong. classic. 🍓

---

💜 ERRORS 💜

the read(), readv(), pread() and preadv() system calls will succeed unless:

• [EBADF] — the fd argument is not a valid file or socket descriptor open for reading. like, bestie, that's not a thing you can read from.
• [ECONNRESET] — the fd argument refers to a socket, and the remote socket end is forcibly closed. the other side just hung up on you. rude. 😤
• [EFAULT] — the buf argument points outside the allocated address space. you pointed at nothing, girl.
• [EIO] — an I/O error occurred while reading from the file system.
• [EINTEGRITY] — corrupted data was detected while reading from the file system. the data arrived and it was wrong. 💀
• [EBUSY] — failed to read from a file, e.g. /proc/<pid>/regs while <pid> is not stopped.
• [EINTR] — a read from a slow device (i.e. one that might block for an arbitrary amount of time) was interrupted by the delivery of a signal before any data arrived. not you getting jumpscared by a signal mid-read 😭
• [EINVAL] — the pointer associated with fd was negative.
• [EAGAIN] — the file was marked for non-blocking I/O, and no data were ready to be read. nothing's here yet, come back later.
• [EISDIR] — the file descriptor is associated with a directory. directories may only be read directly if the filesystem supports it and the security.bsd.allow_read_dir sysctl MIB is set to a non-zero value. for most scenarios, the readdir(3) function should be used instead. read the room, read the directory with the right function 🎀
• [EOPNOTSUPP] — the file descriptor is associated with a file system and file type that do not allow regular read operations on it.
• [EOVERFLOW] — the file descriptor is associated with a regular file, nbytes is greater than 0, offset is before the end-of-file, and offset is greater than or equal to the offset maximum established for this file system.
• [EINVAL] — the value nbytes is greater than INT_MAX.

---

🌈 and also, for readv() and preadv() 🌈

in addition, readv() and preadv() may return one of the following errors:

• [EINVAL] — the iovcnt argument was less than or equal to 0, or greater than IOV_MAX.
• [EINVAL] — one of the iov_len values in the iov array was negative.
• [EINVAL] — the sum of the iov_len values in the iov array overflowed a 32-bit integer.
• [EFAULT] — part of the iov array points outside the process's allocated address space.

---

🧚 and for pread() and preadv() 🧚

the pread() and preadv() system calls may also return the following errors:

• [EINVAL] — the offset value was negative.
• [ESPIPE] — the file descriptor is associated with a pipe, socket, or FIFO. no seeking for you, babe.

---

🫶 SEE ALSO 🫶

dup(2), fcntl(2), getdirentries(2), open(2), pipe(2), select(2), socket(2), socketpair(2), fread(3), readdir(3)

---

📜 STANDARDS 📜

the read() system call is expected to conform to ISO/IEC 9945-1:1990 (“POSIX.1”).

the readv() and pread() system calls are expected to conform to X/Open Portability Guide Issue 4, Version 2 (“XPG4.2”).

---

🕰️ HISTORY 🕰️

• the preadv() system call appeared in FreeBSD 6.0.
• the pread() function appeared in AT&T System V Release 4 UNIX.
• the readv() system call appeared in 4.2BSD.
• the read() function appeared in Version 1 AT&T UNIX.

---

okay that's the whole page, bestie, you ate it up 💅 this one came from the Debian crew, dated March 30, 2020, and it's filed right here in READ(2). go forth and read responsibly, mwah 🎀✨💖