It would be nice if file descriptors on 64-bit platforms used tagging so the full value could never be reused.
E.g. lower 32 bits is the normal fd and the 32-bit is a serial number (or random value). When using the fd the kernel can use the lower 32-bit as index into the table and check the upper 32 bits are correct.
https://pubs.opengroup.org/onlinepubs/9699919799.2018edition...
> 2.14. File Descriptor Allocation
> All functions that open one or more file descriptors shall, unless specified otherwise, atomically allocate the lowest numbered available file descriptor
One could make an unprincipled exception for them, of course. And SQLITE would still need the special-casing to prevent using low-numbered fds. But this would prevent other problems and is worth considering.
In the case that you linked to in the sibling comment that you wrote in reply to me, the dup2 syscall is used.
So the question then that I have is, in the case of
foo 2&>1
a) First close fd 2, and then call dup(1), or does it
b) Call dup2(1, 2), or
c) Do something else entirely, or something more complex or convoluted?
In case the answer is b) then it seems to me, though I may be overlooking something, that we could allow calls like b) and inside of the dup2 syscall keep the id of the fd that we are using as newfd, since it is unambiguously requested that this is intended, while at the same never reusing fd id in the dup syscall.
In this comment I am referring to the dup and dup2 syscalls as defined in the Linux man pages:
dup() uses the lowest-numbered unused descriptor for the new descriptor.
dup2() makes newfd be the copy of oldfd, closing newfd first if necessary, but note the following: [...]
https://linux.die.net/man/2/dup2
With the modification that “lowest-numbered unused descriptor” would be unique as previously stated in the comment that the two of you are replying to.
More generally, the question is, does any wide-spread piece of code manually close an fd and then call the dup syscall, and expect the fd id to be exactly the same as the one they themselves closed, instead of using dup2?
And furthermore, likewise, does any widespread piece of code use the dup2 syscall to specify the newfd where actually it should not have cared about the id of the newfd and should have used dup instead and let the system decide?
write(STDERR_FILENO,"test",4); // OK, write to normal stderr
close(STDERR_FILENO);
open(....); // Open some log file
// later
write(STDERR_FILENO,"x",1); // OK, write to log file
So the conclusion is that the answer to my original question is probably like you say, we can’t just do that.
But it would be interesting to find out how many wide-spread pieces of open source code do it that way, and for all code that does one could submit patches to change them to using the explicit dup2.
It might be possible with some hacks/heuristics to catch many errors (perhaps one could create a valgrind tool/santizier), but I suspect it's not possible in general since there's no way of knowing if the call to write(2,....) meant the old stderr or the new one.
How weird would it look? How likely is it to arise in practice?
I'm a believer in standards in general, but there's a time and place to move beyond them too.