Find a better way to handle `dup2` vs `dup3` differences about rustix HOT 3 CLOSED

It may be silly but rustix could be cleaver and just have one API:

pub fn dup<Fd: AsFd>(fd: Fd, into: Option<&OwnedFd>, flags: DupFlags) -> Result<()>

This would handle the 4 functions at once:

• dup
• dup2
• dup2_with
• fcntl_dupfd_cloexec

With the sale behavior of dup3 if the two file descriptor are equal.

from rustix.

What would be in DupFlags? I think fnctl_dupfd_cloexec really wants to take a RawFd and not an Option<&OwnedFd> for the lower bound for example.

It seems hard to avoid some...duplication here; I think I'd lean more towards having the API match the Linux system calls, and just ensuring the documentation makes things clear.

from rustix.

I'm leaning that way too. These functions are all superficially similar, but they have different use cases: "I want a copy of this fd with an independent lifetime" vs. "I want to overwrite this existing fd with something else". We'll eventually have different documentation for these different use cases. It's also nice if we can avoid having applications transitively depend on system calls they aren't using, where feasible.

FreeBSD also has a dup3 which follows the Linux behavior. So I'm leaning towards just renaming rustix's dup2_with to dup3 and just documenting that. Rustix sometimes tries to present things in more intuitive ways, but in this case, there are enough variations with enough subtle behavioral differences that there's a risk we'd just make it even more confusing if we tried to simplify.

from rustix.