Re: lib/45148: dup2(3) and dup3(3) should support EINVAL

[christos%zoulas.com@localhost (Christos Zoulas)]

The following reply was made to PR lib/45148; it has been noted by GNATS.

From: christos%zoulas.com@localhost (Christos Zoulas)
To: gnats-bugs%NetBSD.org@localhost, lib-bug-people%netbsd.org@localhost, 
        gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, 
jruohonen%iki.fi@localhost
Cc: 
Subject: Re: lib/45148: dup2(3) and dup3(3) should support EINVAL
Date: Sat, 16 Jul 2011 17:52:14 -0400

 On Jul 16,  8:45pm, jruohonen%iki.fi@localhost (Jukka Ruohonen) wrote:
 -- Subject: Re: lib/45148: dup2(3) and dup3(3) should support EINVAL
 
 | The following reply was made to PR lib/45148; it has been noted by GNATS.
 | 
 | From: Jukka Ruohonen <jruohonen%iki.fi@localhost>
 | To: Martin Husemann <martin%duskware.de@localhost>, 
gnats-bugs%NetBSD.org@localhost,
 |      netbsd-bugs%NetBSD.org@localhost
 | Cc: Christos Zoulas <christos%NetBSD.org@localhost>
 | Subject: Re: lib/45148: dup2(3) and dup3(3) should support EINVAL
 | Date: Sat, 16 Jul 2011 02:35:28 +0300
 | 
 |  On Fri, Jul 15, 2011 at 11:56:58AM +0300, Jukka Ruohonen wrote:
 |  > From a quick look, there is also a small defect in the manual page: how 
can
 |  > dup2(2) or dup3(2) ever fail with EMFILE? (Also SUSv4 omits this for 
dup2(2).)
 |  
 |  Can martin@ or christos@ comment about the avove? Surely it must be
 |  impossible to fail with EMFAIL if these always close a descriptor...
 |  
 
 The only case the file descriptor code can return EMFILE is through the
 fd_alloc() path, and only dup() calls this; not dup2() or dup3().
 
 christos