ChristianBiere@gmx.de writes:

> >Number:         17746
> >Category:       lib
> >Synopsis:       FD_ZERO, sysconf(_SC_OPEN_MAX) and select() don't work together

> This means an application must not use the result of 
> sysconf(_SC_OPEN_MAX) and use this as the first parameter for
> select() if this value is higher than FD_SETSIZE. As the admin
> may always increase this limit (kern.maxfiles, 
> proc.curproc.rlimit.descriptors.soft, 
> proc.curproc.rlimit.descriptors.hard) FD_SETSIZE and _SC_OPEN_MAX
> can never be in sync.
> 
> >How-To-Repeat:
> Look at e.g. pkgsrc/x11/aterm and what it does with select() in
> command.c.
> >Fix:
> I don't know whether this can be fixed at all but it should be
> documented.

It is documented, in select(2) - which seems like the best place for
it.  poll(2) is also cross referenced, which avoids this limitation.

BUGS
     Although the provision of getdtablesize(3) was intended to allow user
     programs to be written independent of the kernel limit on the number of
     open files, the dimension of a sufficiently large bit field for select
     remains a problem.  The default size FD_SETSIZE (currently 256) is some-
     what larger than the current kernel limit to the number of open files.
     However, in order to accommodate programs which might potentially use a
     larger number of open files with select, it is possible to increase this
     size within a program by providing a larger definition of FD_SETSIZE be-
     fore the inclusion of <sys/types.h>.