Are you sure such code exists? Doesn't the standard tell you to always treat the fd type as opaque anyway?
Referring to exactly the point you cite, the standard seems to be making no strong statement at all. It says to allocate from the lowest fd but that calls which may return multiple fds do not need to guarantee they are adjacent. I always took this to mean the values should pack downward and should not be e.g. allocated randomly, though it never seemed clear to me why, as the standard seems to be planning for multithreaded code.
So you are interpreting it one way, but the same statement seems to imply that fds are not meant to be introspected and should always be taken at face value from a call that generates a valid fd.
> I always took this to mean the values should pack downward and should not be e.g. allocated randomly, though it never seemed clear to me why,
The reason for this requirement is that early versions of Unix did not have dup2(), only dup(). It has nothing to do with multi threading as this predates pthreads by more than two decades. The shell (sh) makes use of the lowest numbered property to redirect standard in/out/error when setting up pipelines:
int pipes[2];
/* ignore errors */
(void) pipe(&pipes);
if (fork()) {
close(0);
/* guaranteed to return 0 */
(void) dup(pipes[0]);
close(pipes[0]);
close(pipes[1]);
exec_child();
} else {
close(1);
/* guaranteed to return 1, we know 0 is taken */
(void) dup(pipes[1]);
close(pipes[0]);
close(pipes[1]);
exec_parent();
}
Code like this exists in literally every POSIX shell. Anyone saying code like this isn’t common has no idea what they’re talking about.
> says to allocate from the lowest fd but that calls which may return multiple fds do not need to guarantee they are adjacent.
If the program has fd 0-3 and 5 open, socketpair should return 4 and 6, which are not adjacent. If socketpair is called again, while close(N) (N < 7) is being called in a separate thread, you could get {7, 8}, {N, 7}, or {7, N}, depending on kernel and timing details. All of those returns fit the requirement that the fds be allocated lowest first, but may or may not be adjacent or in absolute order.
Referring to exactly the point you cite, the standard seems to be making no strong statement at all. It says to allocate from the lowest fd but that calls which may return multiple fds do not need to guarantee they are adjacent. I always took this to mean the values should pack downward and should not be e.g. allocated randomly, though it never seemed clear to me why, as the standard seems to be planning for multithreaded code.
So you are interpreting it one way, but the same statement seems to imply that fds are not meant to be introspected and should always be taken at face value from a call that generates a valid fd.