[PATCH] support: Close original descriptors in support_capture_subprocess

Florian Weimer fweimer@redhat.com
Sat Dec 1 20:07:00 GMT 2018


* Andreas Schwab:

> On Dez 01 2018, Florian Weimer <fweimer@redhat.com> wrote:
>
>> * Andreas Schwab:
>>
>>> On Dez 01 2018, Florian Weimer <fweimer@redhat.com> wrote:
>>>
>>>> diff --git a/support/support_capture_subprocess.c b/support/support_capture_subprocess.c
>>>> index 6d2029e13b..e1efcd52b0 100644
>>>> --- a/support/support_capture_subprocess.c
>>>> +++ b/support/support_capture_subprocess.c
>>>> @@ -72,6 +72,10 @@ support_capture_subprocess (void (*callback) (void *), void *closure)
>>>>        xclose (stderr_pipe[0]);
>>>>        xdup2 (stdout_pipe[1], STDOUT_FILENO);
>>>>        xdup2 (stderr_pipe[1], STDERR_FILENO);
>>>> +      if (stdout_pipe[1] > STDERR_FILENO)
>>>> +        xclose (stdout_pipe[1]);
>>>> +      if (stderr_pipe[1] > STDERR_FILENO)
>>>> +        xclose (stderr_pipe[1]);
>>>
>>> Is there any reason pipe would have handed out 0, 1 or 2?
>>
>> It really should not have happened unless the caller (the test case) has
>> closed the 0/1/2 descriptors.  That should not happen, but maybe there
>> will be a test some day where this is needed.
>
> If one of them is 0 you still want to close it, don't you?

Hmm.  We create four descriptors:

  int stdout_pipe[2];
  xpipe (stdout_pipe);
  int stderr_pipe[2];
  xpipe (stderr_pipe);

This means that stdout_pipe[1] is at least 1 and stderr_pipe[1] is at
least 3.  We can never close descriptor 0, but the first xclose could
close descriptor 1 or 2.  Should I remove the second if condition?

Thanks,
Florian



More information about the Libc-alpha mailing list