select() ought to just fail with EINVAL if nfds is too large. There's probably an argument for the macros as well to fail by default if the file descriptor given is too large.
https://github.com/bminor/glibc/commit/a0f33f996f7986dbf3763...
The kernel side interface probably won't change because apparently legitimate apps have been allocating fd_sets on the heap to monitor fds > 1024 and they don't want to break those:
https://sourceware.org/bugzilla/show_bug.cgi?id=10352#c7
The underlying problem was also discussed in an article by Lennart Poettering (of systemd fame) and posted to HN back in 2021:
Rightly so. Before libev, AIO or whatever where a thing, I used to run network servers 10 or 15 years or so ago with a redefined __FD_SETSIZE set to 16384 without any problems on Linux (plus appropriate proc and ulimit settings). The whole stack properly supported it, even if not officially supported.
The real problem nowadays is, people can easily receive a fd >= 1024 as you do not control them, and then put them into fd sets only supporting values up to 1023 and then you have a security problem. Plus of course, the later APIs also simply scale better beyond 16k connections.
I both miss and don't miss the days before epoll(2) et al.
If my memory serves me right, we did try poll(2) though a while after it became available (and we already ran the 16k selects) but it was simply less performant.
Later on, when java.nio came around and Java finally could "compete" for network services therefore, we switched from C to Java completely for that service.
[1] https://wiki.ubuntu.com/ToolChain/CompilerFlags#A-D_FORTIFY_...