Those environments support more than SHRT_MAX descriptors in a process. It's only fopen and fdopen with this quirk. Looking at the OpenBSD source code, both fop

Those environments support more than SHRT_MAX descriptors in a process. It's only fopen and fdopen with this quirk. Looking at the OpenBSD source code, both fopen and fdopen explicitly check the descriptor value (which is an int, locally) and return EMFILE if it's above SHRT_MAX. See https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/stdio/fopen.c.diff?r1=1.5&r2=1.6 https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/stdio... and https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/stdio/fdopen.c.diff?r1=1.5&r2=1.6 https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/stdio... Also, maybe select is a bad example as the type of struct fd_set is unrelated to the type used to store a descriptor. It's just a bitfield which can be any arbitrary integral type. On OpenBSD it's uint32_t. Perhaps you had in mind the internal array size used for the bitfield, which is a commonly encountered landmine. But that applies to select specifically, and Linux has the same problem to the same degree. poll might be a better example, but struct pollfd already uses an int for the .fd member in all those environments. pid_t and the value range of an exit status code are open issues currently causing pain not just for ABI compatibility but also API compatibility, both in practice (headaches with Linux syscalls) and with POSIX (bugs and debate on the committees). pid_t is a fairly standard issue--there are several APIs that take a pointer to pid_t, but also pid_t is conflated with int in some APIs (I forget which). Exit value is more problematic because a program can return an int-ranged value, but wait(2), waitpid(2), etc, take a pointer to int for the status argument, which encodes not only the exit value but additional metadata like the reason for exiting. Moreover, traditionally the exit value has always been encoded in 7 (or 8?) bits in the status value. These issues also bleed over into shell semantics. The next version of POSIX will address this by adding some constraints and explicit caveats to the permissible exit value range. Another interesting case is sigset_t, which must be statically sized. But arguably that's more a feature than a bug. Attempts at substantially increasing the signal number range (e.g. with real-time signals) turned out to be bad for other reasons and good examples of when dynamic limits can be bad design.