On Wed, Jul 08, 2015 at 09:30:47PM +0200, Markus Wichmann wrote:
> On Wed, Jul 08, 2015 at 12:00:35PM +0200, Roberto E. Vargas Caballero wrote:
> >
> > > We are ignoring return value of dup(), so just remove it.
> >
> >
> > From dup(3):
> >
> > The dup() system call creates a copy of the file descriptor
> > oldfd,
> > using the lowest-numbered unused descriptor for the new descriptor.
> >
> >
>
> Yes, but can't dup() fail? Shouldn't we at least check or that?
No, it cannot. From dup(2):
ERRORS
EBADF
oldfd isn't an open file descriptor, or newfd is out of
the allowed range for file descriptors.
EBUSY
(Linux only) This may be returned by dup2() or dup3()
during a race condition with open(2) and dup().
EINTR
The dup2() or dup3() call was interrupted by a signal;
see signal(7).
EINVAL
(dup3()) flags contain an invalid value. Or, oldfd was
equal to newfd.
EMFILE
The process already has the maximum number of file
descriptors open and tried to open a new one.
Any of them apply here.
I'm beginning to think that maybe it is a good idea to change the
call to dup to dup2, not due to the lateral effect or to the error
handling, due to we have calls to dup2 in the same function and we
will also remove a line of code, so I will accept such patch.
Regards,
