select() in ULTRIX 1.2

[Powell]

I don't remember this bug being reported before so here goes:

ULTRIX 1.2 is semi-4.2BSD compatible but 4.2BSD will not exhibit
this bug:

Repeat-By:
----------------------------------------------------
Obtain a valid file descriptor such as the value 3.  Setup the readfd mask
for the select call and issue the following commands twice:

readfd = (1 << 3);
if (select(getdtablesize(),&readfd,0,0,0) < 0)
	fprintf(stderr,"Error in select %d\n",errno);
else
	fprintf(stderr,"select ok\n");

The second time and probably all remaining times that select is called,
it will fail with the error number corresponding to invalid file descriptor.
It does not close the file descriptor.  What happens is that some value
within the select call is overwritten during the first call and causes
subsequent calls to fail.

Fix:
----------------------------------------------------
Get ULTRIX sources or get 4.3BSD. :-)
Since that is probably to costly the following is provided.

Work-around:
----------------------------------------------------
Replace the getdtablesize() with the expression (8 * sizeof readfd) for
portability.

Explanation:
----------------------------------------------------
It is not getdtablesize() that is broken.  Replacing getdtablesize()
with the constant NOFILE in /usr/include/sys/param.h will also cause
the select call to fail.  The reason is that getdtablesize() and
NOFILE under standard ULTRIX 1.2 are greater than 32 (namely 64).
The readfd parameter is a 32-bit value so it can never tell select() to
poll file descriptors 32 - 63 but apparently select() is looking for
advice about all 64 descriptors because you told it to.  Shame on you :-)
This problem took me about 2 weeks of intense effort to find (2 weeks
that I didn't have) in code that has worked under 4.2 BSD, 4.3 BSD and
under possibly ULTRIX 1.1.  The 4.2 BSD worked because getdtablesize()
and NOFILE are 20 (less than 32), the 4.3 BSD worked because select was changed
to a different format of fd masks.


Well, this is a long winded discussion of something nobody does so
I'll stop here.



					John D. Powell
					PAR Technology
					adiron!jdp