Why are UNIX file descriptors not implemented by their own type, especially in C++? [closed]

Question

I've been using a fair amount of file descriptors recently, and I've been wondering why they're implemented as integers?

It means that they're easy to confuse for other integers, and there's no way of knowing without context what they are, what they point to, whether they're open, etc.

In C, FILE is an opaque struct type. Many people also typedef e.g. status_t as an integer so their function is obvious. It seems the best thing would be to either implement them as an opaque type, or (e.g. in C++) as a class that can take care of some of the implementation, and also clean up the namespace a bit (a call to pipe() or open() seems so innocuous, and it's not obvious what you're piping or opening without context). Like e.g. std::file_descriptor, with constructors/factory functions for creating pipes or opening files and so on.

I hope this is on topic for this site; I've tried to phrase it as "Why was this particular decision made?" If anyone knows somewhere it'd fit better, please let me know.

Answer 1

History, if nothing else. Back in the 1970s, it probably didn't seem like a problem to just use int (and the value was, in fact, an index into a fixed size table). Later, changing it to another type would have broken code.

Answer 2

Your question can be divided in two:

Why is POSIX file descriptor int?

Like most of things in already established tools and libraries, the answer is probably historical reasons. James' answer points this out.

Making the file descriptor opaque is probably a good idea, but not for the reason you mentioned. Making the type opaque is good for having a different type based on some parameters. For example, on some systems you may want a long long as file descriptor. However, as it seems to happen, no one nowhere has needed 2 billion open files at the same time and therefore no one has cared to fix this non-existing problem.

On the other hand, such a thing as typedef int file_descriptor; won't fix any of the problems you mentioned above:

It means that they're easy to confuse for other integers...

If you confuse your variables, I have bad news for you. The compiler won't help you either since file_descriptor and int are the same type, so any operation on one is allowed on the other.

... and there's no way of knowing without context what they are, what they point to, whether they're open, etc.

You can't do that with FILE either. That's why you have functions that query the information you seek and return it, just like with FILE. typedefing the type won't give you any extra information.

Why doesn't POSIX have a C++ wrapper for it?

In short, because except Microsoft, no operating system developer is in love with C++. Windows is barely even POSIX, so there is no hope for Microsoft in trying to improve anything POSIX. Other operating systems which are POSIX-compliant have a C API as the de facto system programming language (partly because as n.m. says, almost all languages can bind to C).

In fact, C++ is popular among application developers, but not as much among system programmers. The POSIX committee doesn't seem to be particularly interested in C++ either. That's why you'd see C and only C solutions and arguments with respect to the POSIX API. Also note that POSIX was created to standardize UNIX's interface in particular, which was written in C and one of its most important descendants, Linux, is also strongly bound to C.