I see that pid_t is typedef'd in unistd.h, and file descriptors are defined to be int in fcntl.h. But since they are used in similar ways, wouldn't it make sense to have a typedef for file descriptors?


Before reading the other responses, my guess was that pid_t exists for portability reasons. In the Good Ol' Days, some Unixes had short PIDs, others had int PIDs, so you define a system-specific type for PID. I can't recall any pain involved in using int for a file descriptor, even in the very early days of 64-bitness.


I think that this is a difference in philosophy between the C standard (fcntl.h) and the POSIX standard (unistd.h). C has as few types as are necessary (including size_t and time_t), whereas POSIX has as many types as make code clearer (such as pid_t, gid_t, and size_t).

  • 2
    I don't think the POSIX committee defines new types for the pure joy of the activity. I expect they do it in order to patch up differences between existing *ixes. POSIX is more about aligning existing de facto standards than creating new mechanisms. In this particular case, there was difference among *ixes for the type of a PID value, whereas there has been no such historical difference for FDs. – Warren Young Mar 30 '12 at 20:39

PID can be used for more functional purposes in identifying the unique process in relation to certain parameters (i.e. time, size, duration, etc), making it easier to make calls to the specific PID because the same process can occur multiple times over x amount of time. Where file descriptors don't need a type because the file in itself can easily be called by it's unique name.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.