Under what circumstances does the read() syscall return 0?

Question

I'm looking at the read syscall in Unix, which (at least in Linux) has this signature: [1]

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

Let's assume that the call succeeds (i.e. no negative return values) and that count > 0 (i.e. the buffer actually can store a nonzero amount of bytes). Under which circumstances would read() return 0? I can think of the following:

• When fd refers to a regular file and the end of the file has been reached.
• When fd refers to the receiving end of a pipe, socket or FIFO, the sending end has been closed and the pipe's/socket's/FIFO's own buffer has been exhausted.
• When fd refers to the slave side of a terminal device that is in ICANON and Ctrl-D has been sent into the master side while the line buffer was empty.

I'm curious if there are any other situations that I'm not aware of, where read() would return with a result of 0. I'm especially interested (because of reasons) in situations like the last one in the list above, where read() returns 0 once, but subsequent calls to read() on the same FD could return a nonzero result. If an answer only applies to a certain flavor of Unix, I'm still interested in hearing it.

[1] I know this signature is for the libc wrapper, not the actual syscall, but that's not important right now.

Answer 1

• If the Physical File System does not support simple reads from directories, read() will return 0 if it is used for a directory.
• If no process has the pipe open for writing, read() returns 0 to indicate the end of the file.
• If the connection is broken on a stream socket, but no data is available, then the read() function returns 0 bytes as EOF.