I mean, it's cute that it's in principle possible, but what does it actually do that can't be achieved more cleanly in other ways?
Specifically, the case of freopen when the path argument is null, which was introduced in C99.
freopen does all the open-time actions such as that the "w" mode truncates the file. So that could be why. If we dup the descriptor, we have to call ftruncate to implement the "w" flag. I think if we just open the /proc item, O_TRUNC will do it for us.
The freopen function is wacky in the first place, and obviously the approach has the flaw that (as we learn from the submitted article) that sockets cannot be opened this way.
Obviously, /proc/.../fd was not designed for freopen.
/proc/<other-than-self>/fd is very useful for implementing, e.g. process substitution in Bash:
$ diff -u <(this command) <(that command)
/proc/self/fd/ exists because there is a /proc/self symlink to /proc/<self-pid>/ not necessarily because it's useful for a process to open its own descriptors this way. Other /proc/self things are useful, like /proc/self/exe to find out where your executable is located.
I was wondering more why the Plan9 behavior would be useful - why you would want opening /proc/self/fd/<n> to give you a reference to the same file description instead of giving you a new file description. I assume opening /proc/<other-pid>/fd/<n> doesn't share file descriptions with the other process in Plan9 either, but maybe I'm assuming that wrongly as well.
Well you can't `dup()` an fd that you don't already have, this would let you do it. Assuming I understand the behavior right it doesn't have to be the original program calling `open()`.
If you're running a separate process and trying to debug another process that's running by peeking at its fds, then being able to just `open()` them is easier and less invasive compared to the alternatives for getting a dup'd fd (Ex. force the program to call `dup()` itself and then send the fd over a socket or something).