> Also, can dup2() really return EMFILE [...]?

I think you're right, it can't.

Whether this is good or bad is an interesting question.

I think EMFILE is conceptually different from EBADF in that there is no
conceptual reason one couldn't have the maximum file descriptor value
set to (say) 256 while still allowing at most only (say) 64 descriptors
to be open simultaneously; if this were done, EBADF and EMFILE from
dup2 would be meaningfully decoupled.  As it is - ie, in the current
implementation - those limits are perforce the same because the same
variables are used to control both, so as you noticed it's not possible
for EMFILE to be conceptually correct for a dup2 call without EBADF
also being conceptually correct for that call.  (And when multiple
errors can be correct, there's usually no promise which one is actually
returned.)

> 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.

What the other thread would have to do is change the limit after the
initial checks but before the fd is allocated...unless the max fd and
the open fd count are decoupled.

> 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 ?

It's not clear to me that decoupling the max fd from the open fd count
could ever be useful.  However, I am not prepared to reject the
possibility entirely; I've run into others' "but that can't be useful"
when I think the thing in question is useful too often.  And leaving an
impossible errno in the docs is very cheap; the worst you can get is
error-handling code in userland that never gets triggered - and I have
trouble imagining that any program does anything for EMFILE from dup2()
that it doesn't also do for ENFILE from dup2().

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B