Re: fd_set beyond 1024 problem
Date: Wed, 30 May 2007 11:24:20 +0100
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
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'.
Received on 2007-05-30