The status of files that are not listed in ExtraFiles is not unpredictable: those files are closed. If someone wants to add a doc sentence to that effect, that should be fine.

@ianlancetaylor

The status of files that are not listed in ExtraFiles is not unpredictable: those files are closed.

I'm talking about FDs >= len(cmd.ExtraFiles)+3: I demonstrated a case in which the parent has 2 of them (from shell redirection, hence FD_CLOEXEC unset), and one of them is closed in the child but the other is not. Have you actually read my test case?

Here is another example:

cmd := exec.Command("child-cmd")
cmd.Stdin = os.Stdin
cmd.Stdout = os.Stderr // swapping stdout and stderr
cmd.Stderr = os.Stdout
cmd.Start()

Invocation: $ parent-cmd 0<a 1>b 2>c 3>d 4>e
In child-cmd: 0=a 1=c 2=b 3=d 4=closed (3 is inherited but 4 is closed!)

Without swapping:

cmd := exec.Command("child-cmd")
cmd.Stdin = os.Stdin
cmd.Stdout = os.Stdout
cmd.Stderr = os.Stderr
cmd.Start()

Same invocation: $ parent-cmd 0<a 1>b 2>c 3>d 4>e
In child-cmd: 0=a 1=b 2=c 3=d 4=e (now both 3 and 4 are inherited)

Sorry, you're right; I was very unclear. When I said "files", I mean *os.File values, which are the kinds of values that can be put into ExtraFiles.

But upon reflection even that is not quite right, since if you do use shell redirection and then use os.NewFile to open a redirected descriptor, that *os.File is likely to remain open after an exec, since nothing will set the FD_CLOEXEC flag. So I guess it may take a couple of sentences.

@ianlancetaylor, sorry, you are still missing my point.

I would expect parent FDs >= len(cmd.ExtraFiles)+3 to be never inherited if they have FD_CLOEXEC set (e.g. from os.OpenFile), and always inherited if they have FD_CLOEXEC unset.

But if they have FD_CLOEXEC unset, the result is actually unpredictable, because they may or may not be overwritten during the FD shuffling that happens in the child before execve.

Have you read the example in my previous message? Can you explain why the effect on FD 4 is different between the two programs?

Hmmm, I still haven't looked very closely at this, but that makes me think that this is just a bug. Perhaps the code in syscall should fstat the descriptor before calling dup3.

Yes, nextfd setup here doesn't take into account FDs not included in attr.Files.
Consider also replacing dup[23] in "pass 1" with something like newfd = fcntl(oldfd, F_DUPFD_CLOEXEC, minfd).