In message <20021115112232.I229@snowdrop.l8s.co.uk>, you said:
;
;Wrong see:
;http://www.opengroup.org/onlinepubs/007904975/functions/setrlimit.html
;
;RLIMIT_NOFILE
;    This is a number one greater than the maximum value that the system may
;    assign to a newly-created descriptor.  If this limit is exceeded,
;    functions that allocate new file descriptors may fail with errno set to
;    [EMFILE].  This limit constrains the number of file descriptors that a
;    process may allocate.

Good point.  I didn't know where to find IEEE Std 1003.1-2001 when
I was working on this.

;For select
;http://www.opengroup.org/onlinepubs/007904975/functions/select.html
;has [1]:
;
;The only way I can see to implement this is to make select a static
;(probably inline) function in the header file so that the compile
;time value of FD_SETSIZE can be used.

Yeah.  Too bad it isn't a parameter passed to the kernel in the
select(2) call itself.

Hm.  All IEEE Std 1003.1-2001 says about the definition of the fd_set
structure is that it should be a structure, and it says that select()
may be defined as a macro.  I would be happy with a macro definition
of select for a new system call which passes FD_SETSIZE to the kernel
to properly evaluated.

;Erroring 'nfds > p->p_fd->fd_nfiles' or
;	'nfds >  p->p_rlimit[RLIMIT_NOFILE].rlim_cur'
;will break programs (if only because nfds is likely to be rounded
;up to a multiple of 32).
;
;OTOH silently reducing nfds could leave bits set in the events
;that refer to invalid fd numbers.  This could easily lead to a
;(broken) program looping for ever withc actually reporting an errror.

Either way, it's non-conformant.

;
;Unfortunately the system does need to do something to stop
;select( 0x7fffffff, ... ) locking the kernel solid.

Agreed.

I think it also needs to return an error for any bad fd's which are
set in the fd_set.  Returning EINVAL if nfds is bigger than
the kernel array is an approximation of that.  Certainly not the
best answer though.

-Tad