Daniel Stenberg wrote:
> I've realized that we use fd_set internally, even when we use poll() (in
> the select()-"simulating" function).
>
> If we raise the maximum number of filedescriptors above 1024 and use more
> than 1024 in a libcurl-using application, the FD_SET(), FD_CLEAR() etc
> macros (and even the select() function) write beyond the boundary of the
> fd_set variable and all sorts of funny things happen.
>
> It isn't clear to me what the portable way of raising this limit is for
> fd_set, but I feel a strong urge to fix this issue.

On some platforms you can define FD_SETSIZE before including system
headers, and your definition overrides the default, in the definiton
of `fd_set'.

But on many others, you can't do that. I think this includes Linux.

I don't think there is any portable way to increase the limit for
`fd_set', other than defining your own type and macros.

On many, allocating a larger block of memory will do.

However, I'm not 100% sure, but I vaguely recall that even allocating
a larger block of memory is not sure to work. I vaguely recall some
FD_SET macro having a bounds check and not setting the bit if outside
FD_SETSIZE, and some ancient system where FD_ZERO sets all-ones
instead of all-zeros.

So I suggest defining your own type and macros, if using `poll'.

-- Jamie
Received on 2007-05-30