> The problem is, instead, with the auxilliary support functions, in
> particular with the definition of fd_set. Unlike, for example, FILE,
> which is only user-visible as a pointer, so that tons of programs
> won't have a preconcieved notion of the size of the object, in the
> stardard API the user program handles allocation of fd_set's, and has
> to know the size. This is where BSD blew it, and blew it big time.
>
> Since it is standard practice for programs to do things like:
>
> fd_set fooset;
> int fd;
>
> fd = open(...);
> FD_SET(fd, &fooset);
>
> ... if open() can return a descriptor larger than the size of the set,
> you're dead.
>
> If you can require recoding of programs, the problem becomes easy:
> just make FD_ZERO() allocate dynamic data and require a new function
> FD_FREE() to free it up. Unfortunately, acceptance is not likely to
> be that great.
The current size of fd_set is more than sufficient for most programs,
but there are some exceptions (irc servers etc.) which require much more.
I think it won't make much harm when we leave the fd_set as it is and
add some more functions for creation of fd_set with _given_ size and
then modify the few affected programs to use that.
Martin