On Sat, Nov 16, 2002 at 01:08:11AM +0100, der Mouse wrote:
> >> 	- we can have file descriptor larger than FD_SETSIZE.
> >> 	- we can pass fd_set bitmap larger than FD_SETSIZE okay.
> >> 	  (see usr.sbin/traceroute6/traceroute6.c for instance)
> >> 	so i don't see the need for returning error when nfds > FD_SETSIZE.
> 
> > No - that code is broken, or at least not fully portable.
> 
> > Not least because is assumes the format of fd_set - which is not
> > public.
> 
> Well, FD_SETSIZE is not a constant system-wide.  As the manpage for
> select(2) notes, if you define FD_SETSIZE as a larger-than-default
> value before your includes, you can raise the effective limit and still
> use the FD_* macros without the code having to know anything about the
> format of an fd_set.

Absolutely true - makes it tricky to detect the nfds > FD_SETSIZE
error outside that compilation unit though.

Remember, as well as the non-obvious implementations of fd_set,
using one byte per fd is valid.  As is including a count as the
first member (which FD_ZERO would set and select use to perform
the nfds > FD_SETSIZE, it could also be used to stop FD_SET
overwriting random memory).

Note that traceroute will use poll() on netbsd and is (I think)
unlikely to have a 'large' fd number anyway (it is only looking
for events on one fd).

Mr Woods bin/18955 is similarly broken (the freebsd webcvs doesn't
contain this version of the slect code).
The only really safe way to support fds > (the default) FD_SETSIZE
is to convert the programs to use poll().

	David

-- 
David Laight: david@l8s.co.uk