The subtler issues: * All of the following exist and are distinct: * File descriptor (for as long as it's open) * File descriptor number (can be replaced

The subtler issues: * All of the following exist and are distinct: * File descriptor (for as long as it's open) * File descriptor number (can be replaced by close+open or dup\*; there are also special values like `AT_FDCWD`, `OPENMAX` (not necessarily equal to `FD_SETSIZE` or what `ulimit` limits you to) * Open file description (unchanged across dup and fork ...) * Files (e.g. separate open() calls that happen to refer to the same file, whether by the same name or not) * File names * file descriptors to special files, to things that are not files, to files outside of the current chroot, to files from a directory that has been mounted over, to files that have been moved or deleted * what exactly does mmap hold on to? * recvmsg cmsg can make file descriptors appear. Fortunately this is the most common use of cmsg, but remember you can get more than you request (but IIRC there's no clean way to get the number given, the API is underspecified) * There's really nothing special about file descriptors 0, 1, and 2; they're just a strong convention that processes tend to have open at fork time. In practice, you can live without stdin and stdout, but stderr can be written to by all sorts of library functions. * seriously, use `O_CLOEXEC` by default people! * representing FD ownership can be tricky