3 ms·

That's not really what the problem is. The actual code is fine. The issue is that the definition of `fd_set` has a constant size [1]. If you allocate the memor

That's not really what the problem is. The actual code is fine. The issue is that the definition of `fd_set` has a constant size [1]. If you allocate the memory yourself, the select() system call will work with as many file descriptors as you care to pass to it. You can see that both glibc [2] and the kernel [3] support arbitrarily large arrays (well, in the kernel case you'll run into other limitations... but no memory corruption). [1] https://github.com/bminor/glibc/blob/master/misc/sys/select.h#L59 https://github.com/bminor/glibc/blob/master/misc/sys/select.... [2] https://github.com/bminor/glibc/blob/master/sysdeps/unix/sysv/linux/select.c#L32 https://github.com/bminor/glibc/blob/master/sysdeps/unix/sys... [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/select.c#n625 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

deathanatos 3y ago
> The issue is that the definition of `fd_set` has a constant size I'm well aware. > If you allocate the memory yourself, the select() system call will work with as many file descriptors as you care to pass to it. I'm aware of this, as well. That the kernel interface is more flexible is fine. But the glibc wrapper could sanity-check its arguments. If you're saying the glibc wrapper also is flexible (assuming one allocs their own fd_sets and … somehow that doesn't run afoul of strict aliasing…?) … and thus, to allow that backbreaking exercise of "you can still use it for all its other bugs" cannot sanity check its arguments (because nfds > the FD set size is permitted) … well … good grief.
- jcalvinowens 3y ago
  > I'm well aware > I'm aware of this, as well. I'm really curious.. when you typed those sentences, what possible purpose did you imagine them serving? > If you're saying the glibc wrapper also is flexible Yes, it obviously is. There's a long and storied history around this, which you're clearly ignorant of: programmers have been abusing this interface in exactly the way I'm describing for decades. Suddenly breaking a bunch of old code in the name of making an antiquated interface nobody uses anymore "secure" is just bad policy IMHO.

deathanatos 3y ago

> The issue is that the definition of `fd_set` has a constant size I'm well aware. > If you allocate the memory yourself, the select() system call will work with as many file descriptors as you care to pass to it. I'm aware of this, as well. That the kernel interface is more flexible is fine. But the glibc wrapper could sanity-check its arguments. If you're saying the glibc wrapper also is flexible (assuming one allocs their own fd_sets and … somehow that doesn't run afoul of strict aliasing…?) … and thus, to allow that backbreaking exercise of "you can still use it for all its other bugs" cannot sanity check its arguments (because nfds > the FD set size is permitted) … well … good grief.

jcalvinowens 3y ago
> I'm well aware > I'm aware of this, as well. I'm really curious.. when you typed those sentences, what possible purpose did you imagine them serving? > If you're saying the glibc wrapper also is flexible Yes, it obviously is. There's a long and storied history around this, which you're clearly ignorant of: programmers have been abusing this interface in exactly the way I'm describing for decades. Suddenly breaking a bunch of old code in the name of making an antiquated interface nobody uses anymore "secure" is just bad policy IMHO.