On Thu, Nov 14, 2002 at 04:00:23PM -0800, Tad Hunt wrote:
> 
> Ignore that last mail.  the rlimit is a count.  It has nothing
> to do with the fd numbers.

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.

> I need to think some more on this.

And read the correct specs...

For select
http://www.opengroup.org/onlinepubs/007904975/functions/select.html
has [1]:

Errors
...
    [EINVAL]
	The nfds argument is less than 0 or greater than FD_SETSIZE.

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.

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.

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

	David

[1] posix also requires select to be defined in sys/select.h and
a pselect() function.

Oh - lseek(fd, SEEK_CUR, 0) is a cheap way to validate an fd.

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