If I have fd's 0,1,2 open, I then set the maximum number of open files
allowed to 0, should dup2(2,1) succeed ?

My first guess is "yes" (as both fd's are already open and allocated), but
upon reading the man page, strictly speaking fd 1 is no longer valid when I
make the dup2 call and hence it should "not" succeed..

Also, can dup2() really return EMFILE if the explanation for EMFILE is
"Too many descriptors are active." ?  In the case above, it returns
EBADF, and since the check for EBADF is at the top of sys_dup2(), it
does not appear that NetBSD (1.4) can return EMFILE, ever, for dup2.

Perhaps, if NetBSD were to become threaded in such a way that an fd could
be taken by the same process after the initial checks in sys_dup2() are
complete.  Otherwise, I don't see how dup2() can ever return EMFILE.
In light of this, should either the code or man page be changed or left
as-is in waiting for threading which makes these sort of race conditions
possible and hence this error possible ?

Darren