Is a file descriptor ever NOT open?

Question

Of course a file can be open, or not open.

However, a file descriptor by definition refers to an open file (right?). (Well, except when it refers to something besides a file, like a pipe or what have you. But it's still open.)

I've encountered the phrase "open file descriptor" several times. I believe this is redundant, and that in fact there is no other kind of file descriptor besides an open file descriptor—but I would like to verify this.

Is a file descriptor ever in any other state besides "open"? (When it's closed, doesn't it cease to exist?)

Answer 1

A program executes this:

close(0);

The standard input file descriptor has not changed value, but it is no longer referencing an open file description. It is available for re-allocation. Subsequent attempts to use it in, say, read() will result in EBADF because whilst it is still a file descriptor it is not an allocated one that references an open file description. It is a bad file descriptor.

Further reading

• "close()". The Open Group Base Specifications Issue 7. IEEE 1003.1:2008. The Open Group. 2018.
• "read()". The Open Group Base Specifications Issue 7. IEEE 1003.1:2008. The Open Group. 2018.

Answer 2

This seems a very fine distinction, sorry. Please try not to assume that anyone else will know the same exact definition as you, and make sure any ambiguities can be resolved from context instead. I can write an answer that agrees with you and appears to disagree with other answers, citing the following:

Each file descriptor refers to exactly one open file description

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_258

therefore if it does not refer to exactly one open file description, it cannot be a file descriptor. Also

Once a file is closed, the file descriptor no longer exists, since the integer corresponding to it no longer refers to a file.

http://pubs.opengroup.org/onlinepubs/9699919799/functions/close.html