In article <1emihck.12wb3kj1to4qpbM%p99dreyf@criens.u-psud.fr> you write:
>It seems 0x200 is too much for dup2(). Fine, I can understand there is a
>maximum for file descriptors, but Linux seems confortable with this
>value. We need a workaround for this, since Linux can call dup2() with
>values NetBSD does not accept.

While I agree with der Mouse that this is a red herring, it's easy enough to
work around.  On my NetBSD/macppc system (with your program in thing.c):

cromarty:~$ cc -o thing thing.c
cromarty:~$ ./thing
fd2=-1
dup2 failed: Bad file descriptor
cromarty:~$ ulimit -n 1024
cromarty:~$ ./thing
fd2=512

The hard limit on file descriptors per process on my system seems to be
1772, as opposed to 1024 on a stock Debian GNU/Linux system, so just
remembering to use ulimit before running fd-intensive programs should be OK.

-- 
Ben Harris                                                   <bjh21@netbsd.org>
Portmaster, NetBSD/arm26               <URL:http://www.netbsd.org/Ports/arm26/>