On Thu, 22 Feb 2018 15:06:04 -0600, Scott Cheloha wrote:

> Could that difference effect the behavior of the program in practice?

I don't think so.

> Attached diff is using the file stream functions still, for comparison.
> But the dprintf diff feels more natural; keeping the stream functions
> means mucking with fdopen and the introduction of a label to handle the
> failure case, or a new if clause, which makes the diff even larger.
> So unless you or someone else has concerns about breakage I'll stick
> with dprintf.

That's fine with me.

> > The only thing that concerns me is the possibility of closing the
> > wrong fd if stdin is not actually open (unlikely).  I prefer an
> > idiom like the following:
> > 
> >     if (dup2(fd[0], STDIN_FILENO) == -1) {
> >             syslog(LOG_ERR, "dup2: %m");
> >             _exit(1);
> >     }
> >     if (fd[0] != STDIN_FILENO)
> >             close(fd[0]);
> >     ...
> Ah, I was wondering why other programs around the tree did that.
> The attached diff now does this, I believe.
> How would stdin not be open in this case?  Or is it a more general
> good-to-do-just-in-case when you're piping to stdin?

There's usually no guarantee that stdin, stdout and stderr are
actually open when you execute a program.  The caller could have
closed them.  On OpenBSD, when running a setuid program, the kernel
will open fds 0-2 if not already open (directing them to /dev/null).

Since shutdown is setuid, the kernel will do the right thing but I
still think it is worth using the safer idiom.

 - todd

Reply via email to