This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: FD_SET and FORTIFY_SOURCE
On Thu, Feb 28, 2013 at 05:24:18PM +0100, Florian Weimer wrote:
> On 02/28/2013 02:41 PM, Rich Felker wrote:
> >The problem is that a large amount of otherwise-correct software uses
> >malloc and out-of-bounds FD_SET arguments to work with sets larger
> >than FD_SETSIZE. I have written on the issue before that the "correct"
> >way to do this is allocate an array of fd_set objects and use / and %
> >to address the bit rather than passing an out-of-bounds argument to
> >FD_SET (which invokes UB), but some important software like libevent
> >(if I remember correctly) remains wrong in this regard.
>
> The order of bits is unspecified. The fd_set elements are typically
> words, not bytes, and the bit order of the two access patterns
> differs on big-endian machines. (I believe this has been used as an
> argument that little-endian is the natural order, the Internet not
> withstanding.) I can't believe that your kludge is actually more
> portable than just requiring poll support. 8-)
My "kludge" is
fd_set *fds = malloc(sizeof *fds * (NEEDED+FD_SETSIZE-1) / FD_SETSIZE);
and
FDSET(fd%FD_SETSIZE, fds+fd/FD_SETSIZE);
etc.
This has nothing to do with whether the bit array is treated in units
of bytes or words, and works on all existing implementations I'm aware
of, without invoking undefined behavior in any of the macro
invocations. The behavior of select when passed a max value larger
than FD_SETSIZE may be unspecified, but that's the only issue, and in
reality it just works.
> (Writing a poll emulation on top of select isn't that hard, if you need it.)
It's impossible because poll supports arbitrary file descriptors and
select only supports file descriptors < FD_SETSIZE.
Really, select should just be deprecated. POSIX 2008 mandates poll as
part of base (previously XSI option) so all modern systems should have
it.
Rich