From owner-freebsd-hackers  Sat Oct 14 16:13:10 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id QAA21868
          for hackers-outgoing; Sat, 14 Oct 1995 16:13:10 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA21863
          ; Sat, 14 Oct 1995 16:13:06 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id JAA28668; Sun, 15 Oct 1995 09:07:58 +1000
Date: Sun, 15 Oct 1995 09:07:58 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199510142307.JAA28668@godzilla.zeta.org.au>
To: hackers@freefall.freebsd.org, rdm@ic.net
Subject: Re: getdtablesize() broken?
Cc: current@freefall.freebsd.org
Sender: owner-hackers@FreeBSD.org
Precedence: bulk

>I was messing around with a program that calls select() - for some reason I
>kept getting EINVAL. So I twiddled with the sources a bit, and found that
>giving 64 as the first argument to select() (rather than getdtablesize())
>fixed the error. Is this a problem with one of the two functions? The
>program is known to work on many other systems, and it did for me when I
>was using FreeBSD 2.0, so I don't think it is the problem. (BTW, I'm using
>2.2-current now.)

If you've used the bogus (non-)option OPEN_MAX in your kernel config and
made it > 256, then select() could quite easily break like that.  select()
can't handle more than 256 file descriptors.

Using getdtablesize() as the count arg to select() is wrong anyway.  It
may specify more bits than are in the fd_set struct.  It tells the kernel
to look at a huge number of fd's but the fd's of interest may all be
small, smaller than the fd of the largest open file.  The kernel actually
truncates the count to 1 plus the largest open fd.  It considers this as
`forgiving, slightly wrong'.  For some reason (perhaps to trap misuse of
getdtablesize()), it considers counts > 256 as an error before forgiving.

Bruce